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ABSTRACT 


Program  structure  has  been  discus. ;ed  as  being  an  important 
influence  on  the  ease  with  which  programs  can  be  constructed,  verified, 
understood,  and  changed  Yet  the  notion  of  program  structure  has 
remained  a  vague  and  imprecisely  defined  concept.  This  thesis  proposes 
a  definition  and  a  measure  for  program  structure  and  evaluates  the 
usefulness  of  the  measure  as  a  tool  for  determining  and  controlling 

structure  in  a  program. 

Applications  of  the  measure  require  that  the  assumptions  which 
objects  make  be  precisely  stated.  These  are  defined  to  include 

assumptions  about  the  nature  and  use  of  variables  and  data;  conditions 

relating  to  the  correct  execution  of  the  program;  and  assumptions  about 
the  program  environment  in  which  the  text  is  executed.  Top-down 
programming  by  stepwise  refinement  forms  the  basis  for  a  proposed 
methodology  that  permits  these  assumptions  to  be  stated  as  a  program  is 
constructed. 

The  measure  uses  the  information  theoretic  concept  of  excess 

entropy  -  entropy  loading  -  to  determine  the  extent  to  which  assumptions 
are  shared.  Entropy  loading  calculations  also  provide  a  way  of 
comparing  different  decompositions  of  a  program.  Unfortunately,  finding 
the  best  decompositions  of  all  but  small  programs  seems  intractable. 
Consequently,  several  heuristics  are  stated  that  attempt  to  establish 
bounds  on  the  growth  of  entropy  loadings  for  elaborations  of 
decompositions  suggested  at  early  stages  in  a  development. 

Several  programs  are  developed  using  mechanical  aids  to  record 
assumptions  and  compute  entropy  loadings.  Since  each  development 
preserves  assumptions  at  every  elaboration,  this  information  need  not  be 
deduced  from  program  text  when  the  program  is  studied  or  is  to  be 
modified.  Entropy  loading  figures  at  each  stage  allow  different 
decompositions  to  be  compared  and  provide  either  a  basis  for  choosing  a 
decomposition  or  grounds  for  actually  modifying  the  program  to  achieve 
better  structure.  These  developments  illustrate  the  proposed 

methodology  and  show  that  the  measure  produces  results  that  are  usually 
consistent  with  the  definition  of  program  structure  as  well  as  the 
informal  notion  of  structure  from  the  literature. 

Without  mechanical  aids,  however,  applications  of  these  techniques 
to  practical  problems  would  be  tedious  and  difficult.  This  and  other 
difficulties  motivate  further  research  about  this  important  but  elusive 
property  of  programs:  their  structure. 
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INTRODUCTION 


Dijkstra[DJl-5],  Wirth[W],  Naur[NAl-2],  Parnas[PAl],  and 
Mills[MU-2]  have  stressed  the  importance  of  designing  software  as 
collections  of  small  programs,  whose  interrelations  are  well  understood. 
Such  software  is  said  to  have  good  structure.  Unfortunately,  not  every 
piece  of  software  which  consists  of  a  collection  of  small  programs  has 
good  structure.  Nor  do  the  informal  methods,  described  in  the  papers 
above,  necessarily  guarantee  good  structure.  The  goal  of  this  thesis 
has  been  to  investigate  the  behavior  of  a  mathematical  tool  -  entropy 
loading  -  as  a  measure  of  the  goodness  of  structure  and  as  a  guide  which 
can  help  to  preserve  good  structure  in  a  collection  of  programs  that 
constitutes  the  decomposition  of  a  piece  of  software 

The  work  of  Simon[SI]  and  Alexander[AL],  concerning  complexity  in 
systems,  and  the  work  of  Dijkstra[DJl-b]  and  Parnas[PAl]  strongly 
suggest  that  system  decompositions  having  good  structure  possess  the 
following  properties: 


(1)  the  information  required  to  study,  understand,  and  verify 
single  parts  of  a  system  is  supplied  in  conjunction  with  those 
parts,  and  relatively  little  information  about  the  rest  of  the 
system  is  required; 

(2)  single  parts  can  be  drastically  changed  -  changed  algorithm, 
changed  data  structures  -  without  requiring  much  knowledge  of 
the  rest  of  the  system  and  without  changing  the  rest  of  the 
system,  i.e.  drastic  changes  can  actually  be  confined  to 
single  parts; 

(3)  should  an  error  occur  as  a  result  of  the  failure  of  one  small 
part  to  function  correctly,  the  error  can  be  localized  to  that 
part  of  the  system  quickly  and  easily,  permiting  the  error  to 
be  repaired  using  only  a  knowledge  of  that  part; 
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(4)  during  system  construction,  distinct  working  groups  can  be 
given  assignments  to  write  separate  sets  of  parts,  and  the 
assignments  can  be  completed  with  very  little  communication 
among  the  groups. 

Many  programs,  even  some  that  are  regarded  as  good  programs,  fail 
to  possess  one  or  several  of  these  properties  -  with  undesirable 
results.  Programs  that  fail  to  meet  these  standards  frequently  require 

that  many  design  decisions  be  understood  before  a  small  portion  of  the 
program  can  be  understood.  Seemingly  unrelated  portions  often  make  many 
subtle  assumptions  about  each  other,  assumptions  that  are  difficult  to 

deduce  from  the  program  text  or  documentation.  Hence,  in  order  to 

change  a  portion,  the  consequences  of  the  change  must  be  understood  in 
the  context  of  a  large  part  of  the  program.  Shared  assumptions  between 
identified  parts  will  be  called  interactions.  Simon[Sl]  and 

Alexander[AL]  suggest  that  by  controlling  these  interactions,  limiting 
the  amount  of  code  that  each  connects,  and  displaying  the  structure  of 
the  program,  the  four  properties  mentioned  above  are  approached. 

In  order  to  control  interactions,  it  is  first  necessary  to 

explicitly  observe  the  assumptions  made  by  parts  of  a  program. 
Techniques  for  making  these  observations  are  demonstrated,  along  with  a 
tabular  format  for  recording  them  once  they  have  been  noted.  This 

record  can  then  be  used  to  compare  different  decompositions  of  the 

program.  The  comparisons  are  made  by  using  an  entropy  loading 
calculation  described  by  van  Emden[vE2].  The  calculation  has  long  been 

used  in  areas  such  as  information  theory,  physics,  and  ecology.  This 
thesis  investigates  its  applicability  to  data  representing  the 
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assumptions  of  program  parts.  The  entropy  loading  measure  was  chosen 
because  it  had  the  potential  for  distinguishing,  in  a  mathematical  way, 
programs  that  possess  properties  consistent  with  good  structure  from 
programs  that  do  not.  This  mathematical  tool  enables  a  designer  to  note 
the  existence  of  interactions  between  the  parts  of  his  design.  As  a 
result,  he  should  be  able  to  better  understand  and  to  control  the 
effects  of  his  assumptions. 

Applications  of  these  methods  produce  results  that  are  usually 
consistent  with  intuitive  notions  -  in  the  sense  of  Dijkstra  and  Wirth 
about  what  constitutes  good  program  structure.  Programs  that  have  been 
regarded  as  "good"  are  shown  to  have  better  properties  than  programs 
regarded  as  "bad".  Several  "good"  programs  have  even  been  improved. 

Several  anomolies  of  the  measure  as  well  as  the  costs  and  difficulties 
encountered  while  applying  it  are  also  discussed. 

The  chapters  that  follow  give  a  definition  of  structure  and 
interaction  and  show  how  the  effects  of  interactions  can  be  measured. 
These  techniques  are  also  demonstrated  on  numerous  examples  that  have 
been  used  elsewhere  [DJ3,W,HE,MK1], 

Specifically, 

Chapter  I  examines  part  of  the  literature  about  software  design.  It 

then  presents  a  definition  of  program  structure  that  motivates  the 

techniques  used  in  this  thesis. 

Chapter  II  describes  how  a  design  methodology  -  structured 

programming[DJl]  -  and  a  proof  technique[H01]  can  be  used  to  find 
the  interrelations  in  a  program.  Interrelations  are  observed  in  an 
example  and  summarized  in  object/assumption  tables. 

Chapter  III  presents  an  entropy  loading  measure  that  can  be  used  to 


INTRODUCTION 


formally  evaluate  the  relative  merits  of  different  decompositions 
of  a  program.  The  advantages  as  well  as  the  shortcomings  of  the 
measure  are  discussed. 

Chapter  IV  demonstrates  the  use  of  the  measure  to  observe  and  control 
program  structure.  Several  examples  are  developed  using  the 
heuristics  described  in  Chapter  III. 

Chapter  V  discusses  and  evaluates  the  results  of  this  thesis. 

Finally,  two  appendices  follow  the  conclusions:  the  first  presents  a 
larger  example  and  the  second  uses  the  measure  as  a  basis  for  discussing 


the  paper,  Compiler  Strudure[MKl]. 


CHAPTER  I 


REVIEW  OF  PREVIOUS  WORK 

This  chapter  begins  by  stating  several  properties  of  programs  which 
seem  to  have  good  structure.  Next,  several  design  methodologies  and 
conventions  for  representing  programs  are  examined  to  see  to  what  extent 
they  lead  to  good  structure.  Each  is  shown  to  have  the  potential  for 
leading  to  bad  structure  unless  the  issue  of  structure  is  explicitly 
considered.  As  a  result  of  this  examination,  a  definition  of  program 
structure  is  proposed  in  terms  of  the  interrelations  among  the  parts  of 
a  program.  The  analysis  and  control  of  structure  motivates  the 
methodology  used  in  this  thesis. 

ASPECTS  OF  GOOD  STRUCTURE 

DijkstraCOn  Our  Inability  To  Do  Much"[DJl,pp  1-3])  points  out  that 
a  person’s  power  of  comprehension  is  too  meager  to  deal  with  all  the 
detail  in  a  large  program.  However,  he  asserts  that  the  computer  owes 
its  existence  to  its  ability  to  execute  large,  complicated  programs. 
Consequently,  we  must  find  ways  to  organize  large  programs  which  allow 
people  to  deal  with  them,  yet  utilize  a  computer  well.  Several 
properties  of  such  programs  are: 

(1)  Ease  of  verification 

Good  programs  can  be  proved  correct  by  dealing  with  only  small 
parts  of  the  program,  regardless  of  whether  the  proof  is  carried 
out  by  a  person  or  a  machine. 


(2)  Ease  of  understanding 
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ASPECTS  OF  GOOD  STRUCTURE 

The  text  of  a  good  program,  along  with  its  documentation,  describes 
the  program  in  sufficient  detail  that  it  can  be  understood,  and 

(a)  Single  parts  of  good  programs  are  understandable  in  terms 
of  their  text  and  documentation.  (In  fact,  the  documentation 
of  a  good  program  is  not  separate  from  the  program.) 

(b)  There  is  an  understandable  path  from  the  abstract  method 
being  implemented  to  the  final  detailed  code. 

(c)  Decisions  along  this  path  are  explicit  and  can  therefore 
be  evaluated  as  either  good  or  bad. 

(3)  Ease  of  maintenance  and  change 

Good  programs,  because  the  effects  of  single  parts  and  the 
assumptions  made  by  them  are  understandable,  can  be  changed  and 
maintained  with  relative  ease  Little  effort  need  be  spent 
deducing  the  consequences  of  changes  when  compared  with  the  effort 
needed  to  implement  t tie  changes. 

Dijkstra  has  demonstrated  the  role  the  structure  of  a  program  plays. 
His  observations  were  motivated  by  the  verification  issue.  For  example, 


he  cites  the  problem  of  verifying  the  correct  behavior  of  a  hardware 


multiplie 

r[DJl],  If  we 

regard  the 

device  as 

li 

a 

'black  box",  then  all 

possible 

multiplications 

must  be 

performed 

and 

verified  as  being 

correct. 

Alternatively, 

the  internal  structure 

of 

the  device  can  be 

examined,  and  a  convincing  argument  about  the  correctness  of  the  device 


can  be  produced.  This  second  approach  is  the  only  feasible  one. 

The  structure  of  a  program  has  direct  effects  on  the  three 
properties  of  good  programs  mentioned  above.  Some  of  these  effects  are: 

(1)  Program  verification  is  tractable  if  the  amount  of  detail 
required  for  the  verification  can  be  comprehended  by  the  human  or 
mechanical  verifier.  This  means  that  the  parts  of  a  program  and 
the  relations  among  those  parts  are  sufficiently  simple  that 
theorems  relevant  to  the  correctness  question  can  be  easily  stated 
and  easily  proved. 


im""" 
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(2)  "Understanding  a  program"  is  a  less  formal  view  of  program 

verification.  When  v/e  say  that  we  "understand"  a  program  we  mean 

that  we  understand  how  it  works  -  that  we  believe  it  behaves  the 
way  it  is  purported  to  behave.  Since  we  don’t  attempt  to 
understand  programs  as  "black  boxes",  the  single  parts  and  their 
interrelations  must  be  sufficiently  simple  that  understanding  is 
possible. 

(3)  Maintaining  or  changing  a  program  requires  that  the  places  to 

change  be  found,  the  changes  constructed,  and  the  constructions 

verified.  This  implies  that  the  parts  to  be  changed  must  not  only 
be  identifiable  to  a  programmer  but  that  the  effects  of  those 

changes  in  the  context  of  the  entire  program  be  limited.  Hence, 
the  parts  which  are  to  be  changed  and  their  interrelations  with  the 
rest  of  the  program  must  be  kept  within  a  programmer’s  grasp. 


INFLUENCING  STRUCTURE  -  A  REVIEW  OF  THE  LITERATURE 

A  few  techniques  have  been  proposed  to  help  control  program 
structure. 

Knuth[KNl]  has  described  a  "classic"  paradigm  in  which  a  system  is 
designed  from  the  "top  down"  in  terms  of  subroutines,  and  coded  from  the 
"bottom  up".  He  emphasizes  the  mechanism  of  the  subroutine  as  a  tool 
for  allowing  attention  to  be  focused  on  one  design  decision,  postponing 
the  consideration  of  other  details.  This  approach  can  help  to  display 
the  structure  of  a  program.  However,  the  desirable  properties  of  the 
programs  which  the  methodology  produces  are  never  stated. 

Wirth[W]  provides  examples  where  program  text  is  written  in  a 
top-down,  step-wise  manner.  His  model  pays  particular  attention  to  the 
importance  of  verification  and  mentions  the  potential  difficulties  which 
might  accompany  an  attempt  to  change  a  program.  The  Eight  Queens 

n  il  iiotoa— Muor  rr  i  -  r  i _ ■ - -  J-‘— - -  - - _ _ _ _ 
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Problem,  which  is  presented  as  an  example  in  Chapter  IV,  and  based  on 
the  development  by  Wirth,  shows  a  situation  where  decisions  about 
control  flow  have  been  separated  from  decisions  about  data 

representation. 

Naur[NA2]  states  a  specific  criterion  which  he  claims  should  be 
used  to  guide  decision  making  in  the  design  process.  He  proposes  that 

the  global  requirements  of  a  problem  should  be  used  to  deduce  a  set  of 
"associated  actions  which  guarantee  that  these  requirements  are  always 
met"  -  programming  by  action  clusters.  Here  the  importance  of 
describing  the  effects  of  these  operations  precisely  is  stressed. 
Program  verification  then  becomes  more  tractable  than  otherwise. 
Unfortunately,  the  initial  statement  of  the  problem  used  to  demonstrate 
the  method  is  imprecise,  and  design  decisions  which  precisely  define  the 
problem  to  be  solved  are  never  stated  but  simply  appear  in  the  code. 

Further,  one  of  the  global  requirements  must  be  considered  in  at  least 

one  place  other  than  the  action  cluster  which  was  specifically 
associated  with  it.  This  oversight  regarding  interrelations  among  the 
program  parts  results  in  an  error  which  is  documented  by 
Leavenworth[LE].  In  addition,  Naur  emphasized  the  importance  of 
considering  the  relationships  of  global  properties  as  a  program  is 
written,  but  made  no  attempt  to  display  these  relationships. 

The  issue  of  structure  was  first  stressed  by  Dijkstra[DJl]  in  terms 
of  a  programming  methodology  called  "structured  programming".  Dijkstra 
has  carefully  chosen  his  examples.  Each  represents  the  outcome  of  a 
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careful  search  in  which  many  choices  were  rejected.  These  choices  and 
the  reasons  for  their  rejection  are  seldom  stated. 

Each  example  problem  is  presented  in  terms  of  a  collection  of 
carefully  derived  sub-problems  which  together  solve  the  original 
problem.  The  arrangement  and  relationships  of  these  sub-problems  allow 
the  correctness  of  his  programs  to  be  verified  as  they  are  written. 
Verifications  are  established  by  informal  proofs  of  correctness  and  by 
direct  applications  of  an  axiom  system  due  to  Hoare[H01].  Dijkstra  has 
shown  that  verification  in  terms  of  the  representations  suggested  by  the 
programming  methodology  is  tractable  for  systems  which  are  not  just 
examples  of  the  methods[DJ4]. 

Lastly,  Dijkstra  recognizes  the  importance  of  producing  programs 
which  are  maintainable  and  changable  ("On  Program  Families"[DJl]). 

Mills[MIl,MI2]  and  Baker[BA]  have  adopted  the  structured 
programming  methodology  to  the  extent  that  precise  coding  conventions 
are  selected  in  order  to  convert  programs  containing  parts  which  have 
yet  to  be  elaborated  directly  into  code.  Their  conventions  are 

justified  by  a  "structure  theorem"  due  to  Boehm  and  Jacopini[as 
described  in  an  appendix  to  Mil].  These  conventions  include  maintaining 
a  program  library  of  (perhaps)  dummy  entries  so  that  high  level  program 
texts  -  containing  references  to  code  which  has  yet  to  be  elaborated  - 
can  be  compiled  and  verified.  They  also  observe  a  convention  where  PL/I 
text  representing  any  single  program  part  is  always  less  than  a  page  (55 
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lines)  in  length.  The  verification  aspect  receives  specific  attention 
through  attempts  to  formally  verify  texts.  Besides  formal  verification, 
several  programmers  read  the  texts  and  either  conclude  that  they  are 
correct  or  correct  them.  Some  of  these  conventions,  however,  can  lead 
to  bad  structure.  For  example,  if  orogrammers  are  encouraged  to  read 
the  texts  of  other  programmers,  it  is  possible  that  unstated  assumptions 
which  would  adversely  affect  the  maintainability  and  changability  of  the 
program  will  be  made.  Much  attention  is  paid  to  a  variety  of  control 
structures  eg.,  texts  must  be  go  to-less. 

Besides  these  methodologies,  efforts  have  been  made  to  design  and 
implement  programming  languages  which  restrict  the  kinds  of  syntactic 
structures  that  can  actually  be  used  to  represent  programs.  The  intent 
is  to  eliminate  the  use  of  language  constructs  which  have  a  high 
probability  of  leading  to  poorly  structured,  complex  code.  For  example, 
without  adequate  descriptions  of  the  relationships  among  various  pieces 

of  code  in  a  program,  the  unbridled  use  of  the  go  to  statement  makes  it 
impossible  to  guarantee  good  properties  in  all  but  the  smallest 
programs.  Dijkstra[DJ6]  noted  this  difficulty  and  suggested  that  the 
go  to  statement  be  avoided.  As  a  result,  at  least  one  programming 

language  (BLISS[WRH])  has  no  go  to  statement  and  go  to-less  programming 
is  advocated  as  a  good  programming  practice.  Indeed,  some  go  to-less 
programs  do  not  possess  many  of  the  bad  properties  of  some  programs 

containing  go  to  statements,  but  such  programs,  just  by  virtue  of  the 

absence  of  the  go  to,  are  not  guaranteed  to  have  good  structure. 
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Some  so-called  implementation  languages[Wl,WRH]  have  attempted  to 
make  it  possible  for  cooperating  programmers  to  write  good  programs. 
These  languages  have  eliminated  or  restricted  the  use  of  many  syntactic 
constructs  which  seem  to  lead  to  bad  structure.  None,  however,  is 

accompanied  by  a  methodology  which  suggests  how  it  should  be  used  to 

produce  programs  which  have  good  structure.  That  this  is  a  severe 
shortcoming  is  apparent  in  the  light  of  the  developments  of  TSS/360  and 
the  MULTICS  operating  systems:  TSS  was  written  in  the  assembly  language 
for  the  IBM  360/67,  MULTICS  in  an  implementation  language  based  on  PL/I. 
Both  systems  have  similar  goals.  However,  MULTICS  encountered  many  of 
the  same  development  problems  as  did  TSS. 

Snowdon[SN]  has  described  an  interactive  system  which  attempts  to 

provide  an  environment  which  allows  programs  to  be  expressed  in  much  the 
same  way  as  they  would  be  developed  using  the  structured  programming 
methodology.  But,  even  here,  there  is  no  specific  description  of  how 
the  language  is  meant  to  be  used.  Further,  no  emphasis  is  placed  on  the 
manner  in  which  different  "abstract  machines"  are  or  should  be  related 

to  one  another.  Using  the  language  in  no  way  guarantees  good  structure 
in  the  resulting  programs. 

Parnas[PAl-PA4]  has  addressed  the  issue  of  how  to  produce  pieces  of 
software  which  have  good  properties  by  stressing  the  importance  of 
precise  specifications  for  the  independent  modules  which  make  up  the 
piece  of  software.  The  policy  of  "hiding"  information  which  a  module 
does  not  need  is  used  extensively.  The  only  information  which  is 
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available  to  the  implementor  of  a  module  (and  hence  to  the  module)  is 
presented  in  the  specifications  of  the  modules.  The  effect  of  such  a 
policy  is  to  restrict  interrelations  among  modules  to  those  which  can  be 
deduced  from  the  specifications.  (These  may  still  be  very  subtle.) 
Systems  which  are  produced  using  this  methodology  have  the  following 
properties: 


(1)  Once  the  specifications  for  each  module  have  been  written,  the 
system  can  be  constructed  in  a  straightforward  way,  based  solely  on 
the  information  contained  within  the  specifications. 

(2)  The  system  can  be  verified  as  correct  if  the  specifications 

lead  to  a  correct  solution  of  the  problem  for  which  the  system  was 
designed  and  if  each  module  can  be  verified  as  meeting  its 
specification. 

(3)  The  overall  system  is  understandable  if  its  behavior  can  be 

deduced  from  the  specifications  with  reasonable  ease.  Each  module 

is  understandable  if: 

(a)  the  interrelations  among  the  functions  which  comprise  it 

are  understandable  and 

(b)  the  implementation  of  each  function  is  understandable. 

(A)  Individual  portions  of  the  system  can  be  changed  so  that  the 

good  properties  of  the  system  are  preserved,  but  only  if  those 
changes  are  made  within  single  modules.  So  long  as  a  module  meets 
its  specifications,  it  can  be  freely  changed.  Extensions  to  the 

system,  however,  imply  changes  to  the  specification  itself.  Such 

changes  must  be  consistent  with  those  portions  of  the  system  which 
remain[PA4]. 

If  the  interrelations  which  are  deducible  from  the  specification  are 

numerous  and  complicated,  a  system  may  have  bad  properties  (Note  the 

parallel  between  this  phenomenon  and  programs  produced  using  the 

structured  programming  methodology).  Assigning  tasks  to  modules  is  as 
important  as  the  specifications,  which  may,  themselves,  be  difficult  to 
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write.  Parnas’  work  has  been  criticized  because  he  provides  incomplete 
guidelines  about  how  module  partitions  should  be  constructed.  However, 
the  work  provides  a  framework  which  has  good  implications  for  ease  of 
understanding  and  ease  of  maintenance  and  change.  It  also  provides  a 
model  which  has  been  successfully  used  in  constructing  software  in  many 
versions  with  different  implementations  of  each  module. 

PROGRAM  STRUCTURE:  A  DEFINITION 

Dijkstr a[DJl  -DJ4]  has  demonstrated  a  process  by  which  he  constructs 
programs  that  have  good  structure  but  has  not  emphasized  the  properties 
of  the  relationships  among  the  parts  which  make  the  structure  good.  In 
all  his  examples,  the  relationships  among  the  program  parts  have  been 
few  in  number  and  so  straightforward  as  to  be  easily  neglected.  In 
every  instance,  the  relationships  among  the  sub-parts  inside  a  part  have 
been  far  more  numerous  than  the  relationships  among  the  parts. 
Parnas[PAl]  stated  a  definition  of  program  structure  in  terms  of  modules 
and  connections.  The  modules  are  those  portions  of  a  program  which  are 
specifically  indicated  in  the  written  description  of  the  program  - 
perhaps  its  documentation.  The  connections  among  the  modules  "are  the 
assumptions  which  the  modules  make  about  each  other."  These  connections 
are  much  more  extensive  than  the  calling  sequences  and  control  block 
formats  shown  in  most  descriptions.  The  definition  stated  below  is  a 
modification  of  the  definition  due  to  Parnas.  Objects  are  construed  to 
be  any  program  parts  which  have  net  effects  on  the  state  of  the  program 


REVIEW  OF  PREVIOUS  WORK 
PROGRAM  STRUCTURE:  A  DEFINITION 


14 

or  its  data.  The  term  interaction  is  further  defined  as  a  shared 
assumption  among  two  or  more  objects.  Hence,  the  assumptions  which  the 
objects  of  a  program  make  include  the  connections,  which  in  turn  include 
the  interactions.  Consequently,  we  have  the  definition: 

Program  Structure  is  the  set  of  interactions  which  exist  among 

identified  objects  in  a  program  as  well  as  the  ways  those  objects 

are  organized  to  form  the  whole  program. 

The  definition  implies  that  any  program  possesses  structure.  The 

aspects  of  good  structure  at  the  beginning  of  this  chapter,  however, 

imply  that  programs  having  good  structure  are  constructed  from  objects 

whose  interactions  and  assumptions  are  apparent  or  are  easily  deducible. 

The  key  emphasis  in  this  definition  is  that  good  structure  is  determined 

by  interactions  among  objects  and  not  just  the  organization  of  the 

objects. 

The  definition  motivates  the  model  which  is  used  in  this  thesis  to 
develop  and  represent  programs.  This  model  is  developed  in  Chapter  11, 

but  has  two  properties  which  arise  directly  from  the  definition  of 
program  structure. 

(1)  Objects  are  constructed  in  an  organized  way,  using  the  top-down 
and  step-wise  construction  techniques  of  Dijkstra  and  Wirth. 

(2)  Interactions  are  explicitly  recognized  and  recorded  and  are 
used  to  suggest  ways  of  maintaining  good  structure  in  a  program. 
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SUMMARY 

This  chapter  first  presented  a  list  of  several  aspects  of  good  program 
structure.  Next,  several  programming  methods  were  discussed  with 
respect  to  the  ways  they  influence  program  structure.  Lastly,  a 
definition  of  program  structure,  emphasizing  interactions  among  the 
objects  of  a  program,  was  stated.  This  definition  motivates  the 
methodology  that  is  described  in  Chapters  II,  111,  and  IV. 

In  Chapter  11,  the  nature  of  these  interactions  is  investigated  and 
a  proposal  for  Keeping  track  of  them  is  made. 


I 


1 


i 
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CHAPTER  II 


MAKING  ASSUMPTIONS  EXPLICIT 

This  chapter  first  describes  the  kinds  of  assumptions  which  have 
been  observed  among  the  objects  of  a  program  and  then  describes  a 
methodology  for  actually  displaying  them.  Next,  object/assumption 
tables  are  demonstrated  as  a  way  of  recording  observed  assumptions.  In 
chapter  III,  such  tables  will  be  used  to  state  the  measure  of  program 
structure  which  is  investigated  in  this  thesis.  In  the  remaining 
chapters,  object/assumption  tables  will  be  maintained  for  each  example 
to  which  the  measure  is  applied.  Finally,  an  example  program  is 
examined  in  order  to  observe  the  assumptions  made  by  its  objects  and  to 
demonstrate  the  proposed  methodology. 

OBJECTS  AND  ASSUMPTIONS 

Chapter  I  asserted  that  program  structure  is  determined  by  the 

objects  of  a  program  and  their  interactions,  where  interactions  are 
defined  to  be  assumptions  shared  among  objects.  In  point  of  fact, 

objects  don’t  make  assumptions.  Rather,  assumptions  are  made  by  a 
designer/programmer  and  are  used  as  guides  to  construct  objects. 
Dijkstra[DJl,DJ2]  has  displayed  objects  in  the  form  of  English 
statements  which  describe  the  intent  of  various  parts  of,  as  yet, 

incomplete  programs.  Seldom  are  the  assumptions  which  were  used  to 

construct  them  stated  precisely.  This  situation  first  poses  the 
question  of  what  kinds  of  assumptions  are  made. 
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The  classification  of  assumptions  below  has  sufficed  for  the 
examples  developed  in  this  thesis.  Since  the  notion  of  an  assumption  is 
subjective,  other  researchers  might  wish  to  add  to  this  list. 

(1)  Relationships  which  must  hold  prior  to  the  execution  of  an 
object  in  order  for  its  effects  to  be  realized. 

(2)  Assumptions  about  data,  e.g,  assumptions  about  the  meaning  and 
interpretation  of  values  contained  in  simple  variables  or  data 
structures;  assumptions  about  the  position  of  information  in  data 
structures;  assumptions  about  accessibility  of  data;  etc. 

(3)  Assumptions  about  the  environment  in  which  an  object  is 
executed,  e.g.  frequency  of  use  of  an  object;  order  in  which 
computations  will  be  performed;  machine  precision;  assumptions 
about  factors  outside  the  control  of  the  program. 

(4)  Assumptions  based  upon  mathematical  theorems  which  are  relevant 
to  the  problem  being  solved. 

(These  classifications  will  be  referred  to  in  the  next  section.) 

Next,  the  problem  arises  as  to  how  these  assumptions  can  be  found 
and  stated.  A  tempting  approach  would  be  to  examine  a  complete  program, 
understand  it,  and  record  the  assumptions  which  objects  make  -  the 
objects  being  deduced  by  the  examiner  from  the  code  and  its 
documentation.  In  all  but  the  smallest  programs,  this  approach  is 

extremely  difficult.  Both  objects  and  their  assumptions  must  be  deduced 
from  detailed  code.  This  is  a  result  of  the  so-called 

abstraction/implementation  dilemma,  i.e.  it  is  frequently  possible  to 
find  a  program  which  implements  an  abstraction,  but  it  is  usually 
difficult  to  deduce  the  abstraction  from  an  implementation  of  that 
abstraction. 
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The  only  feasible  approach  is  to  observe  assumptions  as  a  program  is 

i 

being  constructed. 

i 

s 

4 

A  DESIGN  METHODOLOGY  FOR  PRESERVING  ASSUMPTIONS 

The  proposed  methodology  is  based  upon  the  "top-down",  "step-wise 
refinement"  methods  suggested  by  Dijkstra  and  Wirt h.  We  begin  by 
describing  the  original  problem  in  terms  of  a  set  of  assumptions  that 

constrain  the  problem  and  a  set  of  final  conditions  ,  (post-conditions) 

that  describe  the  net  effects  the  program  is  intended  to  produce.  Here, 
it  is  vital  that  the  specifications  of  the  problem  be  precisely  stated. 
A  notation  due  to  Hoare[H01,  H02]  will  be  used  to  describe  this 
situation: 

P  {S}  Q 

Here,  P  are  the  assumptions,  Q  are  the  post-conditions,  and  S  is  program 
text  or  an  explicit  description  of  what  an  object  does.  Next,  S  is 
described  as  an  arrangement  of  "simpler"  computations  whose  effects  are 
meant  to  lead  from  P  to  Q.  Each  "simpler"  computation  possesses  its  own 
pre-conditions  and  post-conditions.  Clearly,  this  descriptive  process 

can  be  continued  as  deeply  as  necessary.  We  iden  I  if  y  these  "simpler" 
computations  -  as  well  as  the  original  S  -  as  the  objects  referred  to  in 
the  definition  of  program  structure.  In  the  past,  objects  have  been 

described  informally  in  English.  Such  descriptions  serve  only  as 
reminders  for  what  the  assumptions  and  post-conditions  of  an  object 
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really  are.  This  kind  of  informality  can  aliow  important  detail  to  be 
neglected  and  can  obscure  the  intent  of  the  object.  Henderson  and 
Snowdon[HE]  showed  an  example  where  this  difficulty  actually  led  to  an 
incorrect  program. 

The  assumptions,  post -conditions,  and  intended  effects  of  each 
object  must  be  precisely  described  so  that  a  program  can  be  verified. 
In  the  example  which  appears  at  the  end  of  this  chapter,  such  a 
correctness  argument  will  be  presented  explicitly. 

The  assumptions  which  are  used  to  construct  an  object  will  be 
identified  by  first  noting  the  post-condition  which  is  meant  to  hold 
after  the  object  is  executed.  Next,  the  effects  of  the  object  will  be 
examined  in  order  to  answer  the  following  four  questions; 

(1)  What  relationships  "must"  hold  prior  to  the  execution  of  the 

object  in  order  for  the  effects  to  lead  to  the  post-condition?  (The 
answers  to  this  question  are  the  "weakest"  such  relationships.) 

(2)  What  kinds  of  actions  are  needed,  permitted,  or  used  with 

respect  to  the  data  or  variables  mentioned  in  the  object  to  insure 
that  the  post-condition  holds? 

(3)  What  information  about  the  context  in  which  the  object  is  meant 
to  execute  is  needed,  permitted,  or  used  to  insure  the 
post-condition? 

(4)  What  theorems  are  needed  or  used  by  the  object  and  what 

theorems  is  the  object  permitted  to  use  in  order  to  insure  the 
post-condition? 

Each  question  corresponds  directly  to  one  of  the  four  classifications  of 

assumptions  listed  at  the  beginning  of  this  chapter.  The  answers  to 
these  questions  constitute  a  set  of  distinct  assumptions  which  are  meant 
to  include  the  connections  and  interactions  described  in  Chapter  I.  A 
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record  of  these  assumptions  will  be  used  by  the  measure  which  is 
described  in  Chapter  III.  These  questions  are  meant  to  be  guides  for 

finding  those  relationships  or  requirements  which  seem  to  determine 
program  structure.  As  the  examples  will  indicate,  these  Kinds  of 

assumptions,  when  associated  with  objects,  allow  applications  of  the 

measure  to  yield  values  which  are  usually  consistent  with  the  definition 

of  structure  from  Chapter  I. 

The  answers  to  question  (1)  have  been  characterized,  in  part,  by 

Dijkstra[DJ5,  yet  unpublished],  as  the  weakest  pre-conditions  of  an 

object.  Dijkstra  has  described  rules  for  finding  these  weakest 

pre-conditions  for  assignments,  conditional  statements,  and  while 

statements,  as  well  as  certain  kinds  of  recursive  procedures.  These 
rules,  called  predicate  transformers,  will  be  used  to  help  derive 
assumptions  for  objects  in  the  examples.  It  should  be  noted,  however, 
that  these  predicate  transformers  are  specific  to  the  target  language 
into  which  the  examples  are  developed.  (The  following  paragraphs  define 
weakest  pre-conditions  and  predicate  transformers  in  more  detail.  These 
paragraphs  may  be  skipped  during  a  first  reading  of  this  thesis.) 

*  *  * 

Specifically,  if  P  represents  a  post-condition  for  an  object  S  and 
fS  is  the  predicate  transformer  for  S  then  fS(P)  represents  the  weakest 
precondition  for  S  which  guarantees  that  P  will  hold  after  an  execution 
of  S.  Dijkstra  provides  criteria  for  finding  predicate  transformers 


that  can  be  applied  to  other  kinds  of  syntactic  constructs  as  well.  The 
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fundamental  idea  is  to  find  consistent  rules  that  provide  weakest 

pre-conditions,  given  a  post-condition  and  a  particular  instance  of  some 
construct.  Even  if  such  a  rule  cannot  be  found  in  general,  an 

assumption  can  usually  be  constructed  for  specific  cases  that  are  of 
interest.  For  example,  if  S  i;  an  assignment,  i.e.  X  «-  E,  then 

f"ASSIGNMENT"(P)  =  P:  E  ->  X 

where  E  is  the  expression  being  assigned;  X  is  the  variable  which  is 
assigned  the  value  of  E;  and  P:  E  ->  X  is  the  predicate  which  results  by 
replacing  all  occurrences  of  X  in  P  by  E.  For  example,  if  S  is 
d  :=  c  +  d  and  Pisa*c+b*d  =  A*B  then  the  weakest  pre-condition 
which  results  from  applying  the  predicate  transformer  is  a  *  c  +  b  *  (c 
+  d)  =  A  *  B. 

The  predicate  transformer  for  binary  selection 
(if  B  then  51  else  52  ) 
is 

f'BINARY  SELECTIONS)  =  (  B  a  fSl(P)  )  or  (  -B  a  fS2(P)  ) 

Similarly, 

f”CONCATENATION"(P)  =  fSK  fS2(P)  ) 
is  the  predicate  transformer  for  51  ;  52. 

Besides  displaying  several  predicate  transformers,  Dijkstra  has 
proven  a  theorem  about  predicate  transformers  which  is  based  on  the 
following  definition: 

If  two  predicate  transformers  fS  and  f S’  satisfy  the  property  that 
for  all  P,  fS(P)  =>  fS’(P)  then  "fS  is  as  strong  as  f S’”  and  ”fS’  is 
as  weak  as  fS". 
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The  theorem  can  now  be  stated: 

Theorem  of  Monotonicity:  Whenever  in  a  predicate  transformer  f S, 
formed  by  concatenation  and/or  selection  and/or  recursion,  one  of 
the  constituent  predicate  transformers  is  replaced  by  one  as 
weak(strong)  as  the  original  one,  the  resulting  predicate 

transformer  is  as  weak(strong)  as  fS. 

For  constructions  such  as  while  B  do  SI  or  repeat  SI  until  B 

explicit  predicate  transformers  are  not  presented.  Instead,  for  the 
while  construction,  the  Fundamental  Invariance  Theorem  for  Repetition 
has  been  proven,  i.e. 

If  S  is  while  B  do  SI  and  Q  is  a  post-condition  for  SI,  then 
((  Q  a  B  )  a  fSl(Q))  3  ((  Q  a  fS(true))  d  fS(  Q  a  -B  )). 

This  theorem  along  with  the  Theorem  of  Monotonicity  can  be  used  to  find 
pre-conditions  which  imply  the  weakest  pre-condition  for  a  while 
construction  or  a  repeat  construction.  For  example,  if 
((Q  a  B)  ^  fSl(Q))  a  (Q  A  fS(true)) 

is  used  to  replace  the  weakest  pre-condition  for  a  while  construction, 
given  (Q  a  -'B)  as  the  post-condition,  then  the  Theorem  of  Monotonicity 
asserts  that  the  pre-conditions  which  result  from  applications  of 
selection,  concatenation,  and  recursion  will  be  as  strong  as  any  formed 
by  using  the  weakest  pre-condition  for  the  while  construction.  Further, 
if 

S;  repeat  SI  until  B 

is  interpreted  as 

SI;  S’:  while  -B  do  Si; 

then 


fSl(((Q  a  ->B)  =  fSl(Q))  a  (Q  a  fS’(true))) 
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is  as  strong  as  fS(Q  a  B).  A  difficulty  arises,  however,  when  we 

attempt  to  display  fS(true)  whenever  S  is  a  while  construction. 

Informally,  fS(true)  can  be  interpreted  as  the  "weakest  pre-condition 
for  S  which  guarantees  that  S  terminates".  It  is  frequently  possible  to 
find  conditions  which  guarantee  termination,  but  it  is  more  difficult  to 

prove  that  a  particular  termination  condition  is  the  weakest.  However, 
any  condition  for  termination,  say  X,  implies  the  weakest  pre-condition 
for  S  to  terminate,  i.e.  X  o  fS(true)  so  that  the  Fundamental 

Invariance  Theorem  for  Repetition  allows 

«Q  a  B)  o  fSl(Q))  =>  «Q  a  X)  fS(Q  a  -B)) 

Hence,  if  <(Q  a  B)  d  fSl(Q))  a  <Q  a  X)  is  used  to  replace  the  weakest 
pre-condition  for  a  while  construction,  given  (Q  a  -B)  as  the 
post-condition,  then,  subject  to  the  conditons  of  the  Theorem  of 
Monotonicity,  this  predicate  will  be  as  strong  as  any  formed  by  using 
the  weakest  pre-conditon  for  the  while  construction. 

t  *  * 

The  notion  of  a  "weakest  pre-condition"  can  be  used  informally  to 
suggest  essential  relationships  which  must  hold  prior  to  the  execution 
of  an  object  which  is  not  yet  represented  in  the  target  language.  In 
short,  these  assumptions  should  insure  that  the  object  is  correct,  given 
the  post-conditions  which  hold  after  the  object  is  executed. 

"Weakest  pre-conditions"  are  simply  relationships  which  must  hold 
prior  to  the  execution  of  an  object  and  do  not  include  descriptions  of 
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the  capabilities  which  must  be  available  to  the  objects.  For  example, 
in  order  to  execute  an  assignment,  access  rights  for  variables  are  not 
mentioned  explicitly,  i.e.  if  a  post-condition  for  d  :=  d  +  c  is 

a*c  +  d*b  =  A*B,  then  even  though  the  assumption 
(a  +  b)*c  +  b*d=A*B  must  hold,  the  assignment  requires  write 
access  to  d  and  read  access  to  d  and  c,  but  requires  no  access  to  a,  b, 
A,  or  B.  Similar  arguments  can  be  made  for  examples  of  assumptions 
about  program  environment  and  assumptions  which  are  theorems  from 
mathematics,  i.e.  assumptions  which  are  answers  to  questions  (3)  and 
(4). 

Assumptions  associated  with  objects  that  occur  at  early  stages  of  a 
development  must  usually  be  deduced  informally.  At  later  stages,  formal 
methods  -  such  as  the  techniques  of  Dijkstra[DJ5]  -  can  be  used  to  find 
some  of  the  assumptions.  It  should  be  clear,  however,  that  the  depth  to 
which  refinements  are  made  is  up  to  the  discretion  of  the  designer.  In 
some  of  the  examples,  refinements  have  been  made  to  tine  statement  level 
in  order  to  apply  Dijkstra’s  techniques  directly.  In  general, 
refinements  which  imply  greater  detail  than  the  constructs  for  which  a 
set  of  predicate  transformers  have  been  found  seems  ill-advised  since 
that  kind  of  detail  involves  operations  which  are  available  to  all  the 
objects.  The  section  in  Chapter  III  which  discusses  the  probability  of 
change  of  assumptions  provides  further  evidence  to  justify  this  choice. 

Since  interactions  are  of  major  interest  when  structure  in  a 

program  is  examined,  the  assumptions  of  an  object  should  be  represented 
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as  a  conjunction  of  single  assumptions.  This  Kind  of  representation 
allows  interactions  to  be  observed  easily.  In  particular,  the  next 
section  describes  a  tabular  scheme  for  recording  assumptions  where  this 
Kind  of  representation  is  particularly  helpful. 

To  summarize,  the  assumptions  associated  with  an  object  should 
describe  its  requirements  as  completely  as  possible. 

The  question  now  arises  as  to  how  objects  should  be  elaborated. 

Each  object  will  be  elaborated  as  an  arrangement  of  sub-objects,  each 
possessing  its  own  assumptions  and  post-conditions.  Frequently,  such  an 
elaboration  may  not  require  all  the  assumptions  which  are  made  by  the 
object  which  is  being  elaborated.  For  example,  if 

P  {S}  Q 

where  P  represents  the  assumptions  of  an  object  {S}  with  post-condition 
Q  and  X  and  Y  can  be  found  such  that  P  o  X  and  Y  o  Q  and  X  {S}  Y  then 

the  elaboration  of  {S}  can  be  made  using  only  the  assumptions  implied  by 

X,  rather  than  all  those  implied  by  P. 

As  an  aid  to  finding  X  and  Y,  we  adopt  the  guideline  suggested  by 
Parnas[PAl]  where  we  attempt  to  describe  {S}  via  a  specification  which 
"hides"  as  many  of  the  assumptions  in  P  as  possible.  This  same 

guideline  can  be  applied  at  the  initial  stage  of  program  development  as 
well.  Any  time  this  guideline  is  used,  however,  we  include  P  ^  X  and 
Y  ^  Q  as  assumptions  of  S. 


(HMMiMiMIrtMlBilBMiBirfciinr  iiii  iMii'iMMiliMiliiirtihiii'ii  n  min  1 1 . . . . . 
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A  common  example  of  information  hiding,  where  these  additional 
assumptions  will  not  be  included,  involves  concatenations  of  several 
objects,  perhaps  the  result  of  some  elaboration.  Weakest  pre-conditons 
associated  with  a  concatenation  of  several  objects  frequently  include 
clauses  which  are  of  no  relevance  to  individual  objects  in  the 
concatenation.  For  example,  if  a  post-condition  for 

x  :=  x  +  1;  y  :=  y  -  1;  is  x  >  4  A  y  <  2  then  the  weakest  pre-condition 
for  x  :=  x  +  1  is  x  >  3  a  y  <  3.  In  order  to  satisfy  the  post-condition 
for  the  concatenation,  the  first  assignment  required  no  information 
about  x  and  the  second  required  no  information  about  y,  but  their 
combined  effects  led  to  the  post-condition.  For  this  reason,  in  a 
concatenation  only  those  clauses  in  a  post-condition  which  are  changed 
as  a  result  of  the  effects  of  an  object  will  be  listed  as  assumptions 
for  that  object.  This  choice  can  be  justified  by  observing  that  if 
A  a  B  {S }  C  a  B  and  no  elaboration  of  S  can  be  made  such  that  A  {S}  C 
makes  B  false  then  A  {S}  C  a  B.  Since  this  is  just  a  theorem  from 
mathematics,  the  section  which  discusses  Probability  of  Change  of 
Assumptions  justifies  the  omission  of  these  unaffected  clauses. 

To  summarize: 

(1)  The  methodology  addresses  programs  in  a  "top-down"  fashion. 

(2)  The  assumptions  which  are  associated  with  each  object  are 
answers  to  the  four  questions  stated  earlier. 

(3)  If  an  object  is  elaborated  and  it  is  possible  to  find  X  and  Y 
such  that  if  P{S}Q  and  P  3  X  and  Y  a  Q  and  X{S}Y  then  P  3  X  and 
Y  =>  Q  will  augment  the  assumptions  associated  with  S. 

(4)  Each  program  will  be  verified  by  showing  that  the  assumptions 
associated  with  that  object  imply  a  pre-condition  which  was  derived 
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by  considering  the  effects  of  the  object  along  with  the 

post-condition  which  is  to  hold  after  it  is  executed. 

OBJECT/ASSUMPTION  TABLES 

In  order  to  record  the  assumptions  which  will  be  associated  with 
objects,  object/assumption  tables  will  be  constructed  for  programs. 

These  tables  will  be  used  extensively  in  Chapter  IV.  The  table  is 
defined  for  all  objects  1  and  assumptions  J  such  that 

1,  if  object  1  makes  assumption  J 

T(I,J)  =  J 

0,  otherwise 

In  the  examples,  some  care  has  been  taken  to  represent  assumptions  as 
conjunctions  of  "simpler"  assumptions,  where  each  conjunct  corresponds 
to  a  column  in  the  object/assumption  table. 

AN  EXAMPLE  OF  OBJECTS  AND  THEIR  ASSUMPTIONS 

The  example  which  follows  is  meant  to  demonstrate  the  way 
assumptions  are  deduced  and  recorded,  and  should  not  be  construed  as 
typical  of  the  amount  of  detail  that  should  be  preserved  in  all 

programs.  The  choice  was  made  to  refine  objects  so  that  the  final 

program  consisted  of  single  statements  or  parts  of  statements,  thus 
displaying  explicit  pre-conditions  -  in  the  Dijkstra  sense  -  as  well  as 

assumptions  of  other  kinds.  As  a  consequence  of  this  detail,  the 

development  proceeds  very  slowly  if  it  is  read  from  beginning  to  end. 
Nevertheless,  if  objects  are  to  be  understandable  without  additional 
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context,  assumptions  must  be  stated  wherever  they  are  made.  For  this 

reason,  a  map  is  provided  that  summarizes  the  example.  The  example  can 
best  be  studied  by  studying  first  the  map  and  then  the  objects  in  terms 
of  their  assumptions,  post-conditions,  and  effects.  Postpone  studying 
the  verifications  and  object/assumption  tables  until  the  program  itself 

is  generally  understood. 

The  objects  of  each  of  the  programs  in  this  thesis  are  described 

by: 

(1)  assumptions  for  the  object. 

(2)  an  explicit  statement  of  the  effects  of  the  object,  i.e.  what 

this  object  actually  does.  (Note  that  the  effects  of  an  object  are 

not  necessarily  the  same  as  the  post-conditions  for  an  object,  e.g. 

the  post-conditions  associated  with  a  particular  assignment 
statement  may  be  quite  different  from  the  net  effects  of  that 

assignment.) 

(3)  post-conditions  for  the  object  -  a  description  of  what  every 
version  of  the  object  must  do. 

(4)  a  verification  and  check  that  the  assumptions  stated  in  (1)  and 

the  effects  stated  in  (2)  imply  the  post-conditions.  (These 
verifications  are  informal.  They  are  presented  only  for  the  first 
few  examples.) 

(5)  a  display  of  that  portion  of  an  object/assumption  table  which 
is  appropriate  to  the  object  (assumptions  which  are  added  as  a 
result  of  hiding  information  from  an  elaboration  are  indicated  by  a 
"+"  in  each  table  rather  than  a  "1"). 

Each  object  will  be  named  by  an  object  name  defined  by: 

<object  name>  ::=  :  <ob jec t  number>  ; 

<object  number>  ::=  <positive  integer>  | 

<object  number>  .  <positive  integer> 

These  names  allow  the  ancestry  of  an  object  to  be  related  to  the  rest  of 
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a  program.  For  example,  if  object  :  1 0, 5.3.2:  is  to  be  elaborated  as 
three  new  objects,  then  the  names  for  the  sub-objects  will  be 
:  10.5.3.2.1:,  -.10.5.3.2.2:,  and  :10.5.3.2.3:. 

For  the  purposes  of  these  examples,  the  target  language  for  the 
programs  can  be  regarded  as  a  dialect  of  ALGOL  60  and  is  identical  with 
a  language  used  by  Di jkstr a[DJ3]. 

A  GCD  COMPUTATION 


:1:  (pg.  31) 


:  1 . 1 :  (32)  :1.2:  (32) 


:1.2.1:  (34) 
(x  ♦-  a) 


-.1.1. 1.1:  (36)  :1. 1.1.2:  (36) 

(while  a  i  b  do 

:1. 1.1.2:;) 


:1.1.1.2.1s  (37) 


:  1 .1.1.2. 1.1:  (39)  :  1. 1. 1.2. 1.2:  (39)  :  1 . 1. 1 .2. 1.3:  (39) 

(  if  a  >  b  then 
:1. 1.1. 2.1.2: 
else 

-.1.1.1. 2.1.3:  ;) 

:1. 1.1. 2.1. 2.1:  (41)  :  1 . 1 . 1 .2. 1 .3. 1 :  (41) 
(a  ♦-  a  -  b)  (b  «-  b  -  a) 


:  1. 1. 1 :  (34) 


Object  :1:  assumes  that  positive  integer  values  are  contained  in 
variables  a  and  b  and  has  the  effect  of  assigning  to  x  the  value  of  the 
greatest  common  divisor  of  the  initial  contents  of  a  and  b  (symbolized 
by  A  and  B,  respectively). 
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Object  :  1 . 1 :  leaves  the  value  of  gcd(a,b)  in  a  and  object  :  1 . 2 :  assigns 
the  value  of  a  to  x. 

The  theorem  that  <gcd(a,b )  =  gcd(A,B)  a  a  =  b)  ^  a  =  gcd(A,B)  is  hidden 
from  :1 .1.1:  and  a  =  gcd(A,B)  is  hidden  from  :  1.2. 1 

Object  :1. 1.1.1:  controls  the  execution  of  :1. 1.1.2:  which  maintains  the 
invariant  (a  <  a’  v  b  <  b’)  a  gcd(a,b)  =  gcd(A,B)>  where  a’  and  b’  are 
the  values  of  a  and  b  prior  to  each  iteration. 

Object  :1.1. 1.2.1:  hides  the  invariant  gcd(a,b)  =  gcd(A,B). 

Finally,  objects  :1. 1.1. 2.1.1:,  :1. 1.1.2. 1.2:,  and  :1 . 1 . 1.2. 1.3: 

implement  a  conditional  statement  which  results  in  (a  <  a’  v  b  <  b’)  A 
gcd(a,b)  =  gcd(a’,b’). 
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A  GCD  COMPUTATION 

This  example,  based  on  a  program  due  to  Dijkstra[DJ3  pp.  33-41], 
is  constrained  so  that  it  uses  neither  multiplication  nor  division  to 
compute  the  greatest  common  divisor  of  two  positive  integers. 


Compute  the  value  of  the  greatest  common  divisor  of  the 

initial(positive)  contents  of  the  integer  variables  a  and  b,  and  leave 
the  result  in  the  variable  x,  without  using  either  multiplication  or 
division.  The  assumption  that  neither  multiplication  nor  division  is  to 

be  used  in  the  program  is  an  assumption  which  must  be  made  by  all  the 
objects.  It  is  identified  as  assumption  "0"  and  in  Chapter  111  will  be 

shown  to  have  no  effect  on  the  possible  ways  of  decomposing  the  program. 

object  :1: 

assumptions:  a  >  0,  b  >  0,  A  symbolizes  the  initial  value  of  a, 

0  symbolizes  the  initial  value  of  b,  a  is  an  integer 
variable,  b  is  an  integer  variable,  write  access  to 
x  is  required,  read  and  write  access  is  required  for 

both  a  and  b,  neither  multiplication  nor  division  is 
to  be  used 

:1:  COMPUTE  THE  GCD  OF  a  AND  b,  LEAVE  THE  RESULT  IN 
THE  VARIABLE  x,  WITHOUT  USING  EITHER  MULTIPLICATION 
OR  DIVISION. 

effects  and 

post-condition:  x  =  gcd(A,B) 

verification:  Since  the  gcd  of  any  two  positive  integers  is  always 

defined  and  is  computable,  the  computation  is 

feasible. 
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The  object/assumption  table  for  :1:  is 
assumptions 

Objects  o  1  23456789  1011 
•*  1  •*  Mill!  M 

0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 

B  symbolizes  the  initial  value  in  b 

3)  write  access  to  x  is  required 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

We  elaborate  :1:  as 

:1.1: 

assumptions:  a  >  0,  b  >  0,  A  symbolizes  the  initial  value  of  a, 

B  symbolizes  the  initial  value  of  b,  a  is  an  integer 
variable,  b  is  an  integer  variable,  read  and  write 
access  to  a  and  b  is  required,  neither 

multiplication  nor  division  is  to  be  used 

:1.1:  REPLACE  THE  VALUE  OF  a  BY  gcd(A,B) 

effects  and 

post-condition:  a  =  gcd(A,B) 

:  1 .2 : 

assumptions:  a  =  gcd(A,B),  write  access  to  x  is  required,  read 

access  to  a  is  required,  neither  multiplication  nor 

division  is  to  be  used 

il.2:  REPLACE  THE  VALUE  OF  x  BY  THE  VALUE  CONTAINED 
IN  a. 

effects:  x  =  a 

post-condition:  x  =  gcd(A,B) 

verification:  In  order  for  x  =  gcd(A,B)  to  hold  after  :1 .2:,  given 

that  its  effect  is  x  =  a,  its  assumptions  must  be  a 
=  gcd(A,B).  But  this  is  guaranteed  as  the 
post-condition  of  :  1 . 1 :. 
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object/assumption  table  for  :  1 . 1 :,  :  1.2: 

0123456789  1011 
:  1-  >:  I  I  1  1  I  II 

:  1-  2‘  l  ill 

0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
B  symbolizes  the  initial  value  in  b 

3)  write  access  to  x  is  required 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

6)  a  =  gcd(A,B) 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 
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Consider  next  an  elaboration  of  :  1 . 1 If  the  values  of  a  and  b  can  be 
modified  so  that  a  =  b  and  gcd(a,b)  =  gcd(A,B)  then  a  =  gcd(A,B).  This 
means  that  by  adding 

(a  =  b  a  gcd(a.b)  =  gcd(A,B))  =>  a  =  gcd(A,B) 

to  the  assumptions  of  :1.1:  we  can  write 

:  1 . 1 . 1 : 

assumptions:  a  >  0,  b  >  0,  A  symbolizes  the  initial  value  of  a, 

B  symbolizes  the  initial  value  of  b,  a  is  an  integer 
variable,  b  is  an  integer  variable,  read  and  write 
access  is  required  for  both  a  and  b,  and  neither 
multiplication  nor  division  is  to  be  used 

:  1.1.1:  MAKE  a  =  b  SUCH  THAT  gcd(a,b)  =  gcd(A,B). 

effects  and 

post-condition:  a  =  b,  gcd(a,b)  =  gcd(A,B) 

An  elaboration  of  :  1 .2:  can  be  made  if  we  observe  that 


and 


a  =  gcd(A,B>  3  true 
x  =  a  o  x  =  gcd(A,B) 


But  since  :  1 . 2 :  assumes  a  =  gcd(A,B)  we  can  write 


assumptions:  write  access  to  x  is  required,  read  access  to  a  is 

required,  neither  multiplication  nor  division  is  to 
be  used 


:  1 .2. 1 :  x  *-  a 


effect  and 
post-condition: 


x 


a 
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As  a  result,  the  object/assumption  table  for  :1.1 
rl.2.1:  is 

01234567891011 
•  1  •  1  •  1  1  1  1  1  4  11 

:  l-  2'  i  i  l  l  *  4 

:  l  •  l  •  l  s  ill  li  li 

*  1  •  2  •  1  •  1  1  1 

0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
B  symbolizes  the  initial  value  in  b 

3)  write  access  to  x  is  required 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

6)  a  =  gcd(A,B) 

7)  (a  =  b)  A  gcd(A,B)  =  gcd(a,b)  o  a  =  gcd(A,B) 

8)  x  =  a  ^  x  =  gcd(A,B) 

9)  a  =  gcd(A,B)  3  true 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 
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Adopting  the  convention  that  a’  and  b’  equal  the  values  of  a  and  b  just 
prior  to  the  most  recent  execution  of  :1. 1.1.2:  we  elaborate 


assumptions:  a  >  0,  b  >  0,  A  symbolizes  the  initial  value  of  a, 

B  symbolizes  the  initial  value  of  b,  a  is  an  integer 
variable,  b  is  an  integer  variable,  read  access  is 

required  for  both  a  and  b,  a’  and  b’  equal  the 

respective  values  of  a  and  b  prior  to  the  last 
execution  of  :1. 1.1.2:,  [(a  <  a’  v  b  <  b’)  a 

gcdfa.b)  =  gcd(A,B)  A  a  t  b)  o  (a  *  b  a  gcd(a,b)  = 

gcd(a’,b’))  A  max(a’,b’)  >  max(a,b)], 

gcd(a,b)=gcd{A,B),  neither  multiplication  nor 
division  is  to  be  used 

:1. 1.1.1:  while  a  i  b  do 


assumptions:  a  >  0,  b  >  0,  A  symbolizes  the  initial  value  of  a, 

B  symbolizes  the  initial  value  of  b,  a  is  an  integer 
variable,  b  is  an  integer  variable,  read  and  write 
access  is  required  for  both  a  and  b,  a’  and  b’  equal 
the  respective  values  of  a  and  b  prior  to  the  last 
execution  of  :1. 1.1.2:,  a  /  b,  gcd(a,b)  =  gcd(A,B), 
neither  multiplication  nor  division  is  to  be  used 

:1. 1.1.2:  DECREASE  EITHER  a,  b,  OR  BOTH  a  AND  b  SUCH 
THAT  gcd(a,b)  =  gcd(A,B). 

effect  and 

post-condition:  (a  <  a’  v  b  <  b’),  gcd(a,b)  =  gcd(A,B) 


effects  and 
post-condition: 


a  =  b,  gcdfa.b)  =  gcd(A,B) 
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The  object/assumption  table  for  :1. 1.1.1:  and  :1. 1.1.2:  Is 

01  23456789  101 1 12131415 

•  1  •  I  •  I  •  1  •  111  1  till 

Si-  1*  1-25  111  11  111  11 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
B  symbolizes  the  initial  value  in  b 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1.1.2: 

13)  <(( a<a’  v  b<b’)  a  gcd(a,b)=gcd(A,8)  a  a^b)  o 

(a/b  a  gcd(a,b)  =  gcd(A,B))  a  max(a’,b’)  >  max(a,b)) 

14)  gcd(a,b)  =  gcd(A,B) 

15)  a  ^  b 

If  we  add  the  following  assumption  to  :1. 1.1.2:  we  can  "hide"  A  and  B 

from  :1.1. 1.2.1: 

[(gcd(a,b)=gcd(A,B))o 

(gcd(a’,b’)=gcd(a,b),  holds  prior  to  executing  :1. 1.1. 2.1:)]  and 

[(gcd(a’,b’)=gcd(aIb),  holds  after  executing  :  1 . 1 . 1 .2. 1  :)=» 

(gcd(a,b)=gcd(A,B))] 

This  is  verifiable  in  the  context  of  :  1. 1.1.2:  and  :1. 1.1.1:. 

:1. 1.1. 2.1: 

assumptions:  a  >  0,  b  >  0,  a  and  b  are  integer  variables,  A 

symbolizes  the  initial  value  of  a  and  B  symbolizes 
the  initial  value  of  b,  read  and  write  access  is 
required  for  both  a  and  b,  a’  and  b’  equal  the 
respective  values  of  a  and  b  prior  to  the  last 

execution  of  :1 . 1 . 1.2:,  gcd(a,b)  =  gcd(a’,b’), 

neither  multiplication  nor  division  is  to  be  used 

:  1.1. 1.2.1:  DFCREASE  EITHER  a,  b,  OR  BOTH  a  AND  b 
SUCH  THAT  gcd(a.b)  =  gcd(a’.b'). 


effects  and 
post-condition: 


(a  <  a’  or  b  <  b’),  gcd(a,b)  =  gcd(a’,b’) 
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The  table  for  :1. 1.1.2:  and  :1.1. 1.2.1:  is 

01  23456789  1011 I2I3I4I5I6I7 

•  1  •  I  •  I  •  2-  III  II  III  I  I  ' 

•  I  •  I  •  I •  2-  I  •  II  II  III  I  1 

0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
B  symbolizes  the  initial  value  in  b 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

12)  a’  and  b1  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :i. 1.1.2: 

14)  gcd(a,b)  =  gcd(A,B) 

15)  a  t  b 

16)  [(gcd(a,b)=gcd(A,B))o 

(gcd(a,,b’)=gcd(a1b)1  holds  prior  to  executing  :1. 1.1. 2.1:)]  and 
[(gcd(a\b’)=gcd(a,b),  holds  after  executing  :1.1.1.2.1:)=> 
(gcd(a,b)=gcd<A,B))] 

17)  gcd(a.b)  =  gcd(a\b’) 
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We  can  now  elaborate  :i. 1.1. 2.1:  as 
:1. 1.1. 2.1.1: 

assumptions:  a  >  0.  b  >  0,  a  and  b  are  integer  variables,  read 

access  to  a  is  required,  read  access  to  b  is 
required,  a’  and  b’  equal  the  respective  values  of  a 

and  b  prior  to  the  last  execution  of  :1. 1.1.2:,  a  t 

b,  (a  >  b  a  gcd(a’,b’)  =  gcd(a-b,b)  v  a  <  b  A 

gcd(a’,b’)  =  gcd(a.b-a),  neither  multiplication  nor 
division  is  to  be  used 

:1. 1.1. 2.1.1:  if  a  >  b  then 

:i. 1.1. 2.1. 2: 

assumptions:  gcd(a\b’)  =  gcd(a-b,b),  a  >  0,  b  >  0,  a  and  b  are 

integer  variables,  write  access  to  a  is  required, 

read  access  to  a  is  required,  read  access  to  b  is 

required,  a’  and  b’  equal  the  respective  values  of  a 

and  b  prior  to  the  last  execution  of  :1. 1.1.2:, 

neither  multiplication  nor  division  is  to  be  used 

:1. 1.1. 2.1.2:  DECREASE  a  BY  b. 

effect  and 

post-condition:  a  has  been  decreased  by  b. 

else 

:1. 1.1. 2.1.3: 

assumptions:  gcd(a’,b’)  =  gcd{a,b-a),  a  >  0,  b  >  0,  a  and  b  are 

integer  variables,  read  access  to  a  is  required, 

write  access  to  b  is  required,  read  access  to  b  is 

required,  a’  and  b’  equal  the  respective  values  of  a 

and  b  prior  to  the  last  execution  of  :1. 1.1.2:, 

neither  multiplication  nor  division  is  to  be  used 

:1. 1.1. 2.1.3:  DECREASE  b  BY  a. 

effect  and 

post-condition:  b  has  been  decreased  by  a 

post-condition:  gcd(a,b)  gcd(a’,b’),  (a  <  a’  or  b  <  b’) 

verification:  given  that  a  ^  b  and  the  other  initial  conditions 

the  assumptions  for  :1. 1.1. 2.1.1:  is  a  theorem  from 
mathematics. 
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The  object/assumption  table  for  these  parts  is  then: 

0  I  23456789  1011121314151617181920 
2  l  -  1  -  1-2-  I  -  I  i  II  1  II  I  I 

Si-  1  -  1  •  2-  1*  22  II  II  I  I 

I  1  ■  1  •  1-2-  1-3!  II  I  II  I 

0)  neither  multiplication  nor  division  is  to  be  used 

I)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

II)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1.1.2: 

15)  a  ^  b 

18)  (a  >  b  a  gcd(a’,b’)  =  gcd(a-b,b)  v 
a  <  b  a  gcd(a\b’)  =  gcd(a,b-a) 

19)  gcdta’.b’)  =  gcd(a-b.b) 

20)  gcd(a’,b’)  =  gcd(a,b-a) 
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Lastly,  if  we  add 


gcd(a’,b’)  =  gcd(a,b-a)  s  true 
b  decreased  by  a  =  gcd(a,b)=gcd(a’,b’) 


to  the  assumptions  of  :1. 1.1. 2.1.3:  and 

gcd(a\b’)=gcd(a-b,b)  3  true 

and 

a  decreased  by  b  3  gcd(a,b)=gcd(a',b’) 
to  the  assumptions  of  :1. 1. 1.2. 1.2:,  we  can  elaborate  these  objects  to 
:1. 1.1. 2.1. 2.1: 

assumptions:  write  access  to  a  is  required,  read  access  to  a  is 

required,  read  access  to  b  is  required,  neither 
multiplication  nor  division  is  to  be  used 

:1. 1.1. 2.1. 2.1:  a  «-  a  -  b. 


effects  and 
post-condition: 


a  decreased  by  b 


:1. 1.1. 2. 1.3.1: 

assumptions:  read  access  to  a  is  required,  write  access  to  b  is 

required,  read  access  to  b  is  required,  neither 
multiplication  nor  division  is  to  be  used 

:1. 1.1. 2.1. 3.1:  b  «-  b  -  a. 


effects  and 
post-condition: 


b  decreased  by  a 
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The  relevant  tables  are: 

0  I  23456789  1011 1 2 13 14 151 61 7 181 9202 1 22 
•*  I  -  I-  I  -  2-  I  -  2‘  II  II  II  1  * 

S  I-  I  -  1-2-  1-  3s  11  1  III  1  * 

:  I  ■  1  •  1-2-  1-2-  Is  I  II  I 

•I-  !•  I  •  2-  I  ■  3-  I*  I  1  II 

0)  neither  multiplication  nor  division  is  to  be  used 

I)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

II)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1.1.2: 

19)  f>cd(a’,b’)  =  gcd(a-b,b) 

20)  gcd(a’,b’)  =  gcd(a,b-a) 

21)  gcdfa’.b’)  =  gcd(a,b-a)  =>  true, 

b  decreased  by  a  o  gcd(a’,b’)  =  gcd(a,b) 

22)  gcd(a’,b’)  =  gcd(a-b,b)  o  true, 

a  decreased  by  b  o  gcd(a,b)  =  gcd(a’,b’) 
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Below  is  a  display  of  the  entire  table.  This  table  will  be  used  in 
chapter  IV  to  evaluate  different  decompositions  of  the  program,  and  to 
observe  where  interactions  were  introduced  as  the  program  was  developed. 
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0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
B  symbolizes  the  initial  value  in  b 

3)  write  access  to  x  is  required 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

6)  a  =  gcd(A.B) 

7)  (a  =  b)  a  gcd(A.B)  =  gcd(a.b)  r>  a  =  gcd(A,B) 

8)  x  =  a  3  x  =  gcd(A,B) 

9)  a  =  gcd(A,B)  =>  true 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :  1 . 1.1.2: 

13)  (((a<a’’  v  bsb1)  a  gcd(a,b)=gcd(A,B)  a  a^b)  => 

(a^b  a  gcd(a.b)  =  gcd(A,B))  a  maxfa’.b’)  >  max(a,b)) 

14)  gcd(a,b)  =  gcd(A,B) 

15)  a  /  b 

16)  [(gcd(a,b)=gcd{A,B))=> 

(gcd(a’1b’)=gcd(a1b),  holds  prior  to  executing  :1. 1.1. 2.1:)]  and 
[(gcd(a’,b’)=gcd(a,b),  holds  after  executing  :  1. 1 . 1 .2. 1  :)=> 
(gcd(a,b)=gcd(A,B))] 

17)  gcd(a,b)  =  gcd(a’,b’) 

18)  (a  >  b  a  gcd(a’,b’)  =  gcd(a-b.b)  v 
a  <  b  a  gcdfa’.b’)  =  gcd(a,b-a) 

19)  gcd(a',b’)  =  gcd(a-b.b) 

20)  gcd(a’,b’)  =  gcd(a,b-a) 

21)  gcd(a’,b’)  =  gcd(a,b-a)  =>  true, 

b  decreased  by  a  ^  gcdOr.b’)  =  gcd(a,b) 

22)  gcd(a’,b’)  =  gcd(a-b,b)  =>  true, 

a  decreased  by  b  =>  gcd(a,b)  =  gcd(a’,b’) 


MAKING  ASSUMPTIONS  EXPLICIT  ^ 

SUMMARY 

SUMMARY 

The  definition  of  program  structure  in  Chapter  1  has  been  used  to 
explicitly  describe  the  kinds  of  assumptions  which  are  associated  with 
objects.  These  assumptions  include  the  "pre-conditions",  described  by 
Dijkstra[DJ5],  as  well  as  assumptions  about  the  capabilities  an  object 

must  have  in  order  to  achieve  its  effects.  Lastly,  a  program  is 

developed  in  order  to  demonstrate  the  way  assumptions  are  preserved  and 
recorded.  The  object/assumption  table  foi  this  program  will  be  used  in 

Chapter  IV  in  order  to  examine  various  decompositions  of  the  program  in 

the  light  of  the  measure  which  is  presented  in  Chapter  III. 


CHAPTER  III 


A  MEASURE  OF  PROGRAM  STRUCTURE 

This  chapter  presents  and  justifies  a  calculation  which  is  used  to 

measure  how  much  groups  of  objects  in  a  program  interact.  Next,  it  is 

shown  that  the  problem  of  finding  an  arrangement  of  objects  which 
interacts  least  is  tractable  only  for  small  programs.  Instead,  several 
theorems  and  heuristics  are  presented  which  provide  useful  guidelines 
for  controlling  interactions  as  a  program  is  developed.  Lastly,  it  is 

observed  that  certain  assumptions  should  affect  structure  less  than 
others.  For  example,  assumptions  which  are  not  subject  to  change  - 
theorems  from  mathematics  -  can  safely  be  shared  without  influencing  the 
difficulty  of  changing  a  program.  Consequently,  the  definition  of  the 
measure  is  modified  to  incorporate  this  notion. 

DEFINITION  OF  A  MEASURE 

Dictionary  definitions  of  the  word  "measure"  use  phrases  such  as 

"reference  standards  to  which  something  is  valued",  "a  criterion",  or 
"extent,  degree  or  quantity".  These  phrases  and  the  definition  of 
program  structure  from  chapter  II  suggest  that  a  measure  of  program 
structure  should  provide  a  valuation  of  the  interactions  among 
identified  groups  of  objects  in  a  program.  Van  Emden[vEl,vE2]  has 
described  a  calculation  based  on  data  contained  in  an  object/assumption 
table  which  characterizes  the  degree  to  which  collections  of  objects 
interact.  The  calculation  is  called  entropy  loading.  Choosing  this 

■>-- . 
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calculation  as  a  measure  of  program  structure  is  justified  if  we  regard 
programs  as  complex  systems  which  have  Identifiable  objects  which,  in 
turn,  possess  properties  -  in  this  case,  an  object  has  the  properties  of 
making  or  not  making  certain  assumptions,  van  Emd;n[vE2]  has  shown  that 
entropy  loading  provides  a  measure  of  what  Williams  and  Lambert[WL]  cal! 
an  "association".  Informally,  this  means  that  the  calculation  indicates 
the  degree  to  which  designated  collections  of  objects  are  similar  to  one 
another  Entropy  loading  measures  the  amount  of  information  shared 

among  collections  of  objects  as  opposed  to  the  information  used  inside 
each  collection.  Alexander^, L]  and  Watanabe[WA]  have  also  used  similar 
techniques  to  analyze  complex  systems.  In  the  present  application, 
where  object/assumption  tables  represent  programs,  designers  can  use  the 
calculation  as  a  guide  for  controlling  interactions  among  collections  of 
objects  which  are  designated  as  subsystems. 

En'  jading  is  defined  for  some  subset  of  the  rows,  say  S,  of 

an  object/assumption  table  containing  n  rows.  Suppose  that  the  objects 
in  S  are  partitioned  into  two  sets  A  and  B  such  that  A  u  B  =  S  and 
A  n  B  =  <empty>.  The  entropy  loading  of  S  for  the  partition  into  A  and 
B  is  defined  to  be 

C(S)  =  H(A)  +  H(B)  -  H(S) 

where 

H(X)  =  £  ,  (n,/n)  log  (n/n j) 

=  log  n  -  (1/n)  1  j  n,  log  (nj) 
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To  determine  the  n/s 

(a)  construct  a  table  containing  only  those  columns  of  S  which 
contain  at  least  one  occurrence  of  a  "1"  in  the  subset  of  rows,  X. 

(b)  regarding  each  row  in  this  table  as  a  one-zero  pattern,  the 
n,’s  are  the  number  of  occurrences  of  each  distinct  pattern  (Note 
that  the  sum  of  all  n,’s  equals  n,  the  number  of  rows  in  S.) 

For  example,  if  a  set  of  rows,  S,  is 

a  b  c  d  e  f 

1 

2 

3 

4 

5 

6 

Let  A  be  the  rows  {1,2,3}  and  B  the  rows  {A, 5, 5),  then  H(S)  =  H(A  U  B)  = 

log  6  since  at  least  one  "1"  occurs  in  every  column,  and  each  row  is 

distinct.  Similarly,  H(A)  can  be  computed  by  noting  that  at  least  one 

"1"  occurs  in  A  only  in  columns  a,  d,  and  f,  and  from 

a  d  f 
1  0  0 
0  0  1 
0  1  0 
0  0  1 
0  0  1 
0  0  0 

1  0  0  occurs  once;  0  0  1  occurs  three  times;  0  1  0  occurs  once;  and 
000  occurs  once,  then 

H(A)  =  log  6  -  (1/6)  3  log  3  (*) 

Similarly,  since  at  least  one  "1"  occurs  in  columns  b,  c,  e,  and  f 
of  B,  0  0  0  0  occurs  twice;  0  0  0  1  occurs  once;  10  11  occurs  once; 
0111  occurs  once;  and  0010  occurs  once,  ano 


H(B)  =  log  6  -  (1/6)  *  2  log  2 
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Finally, 

C(S)  =  C(A  u  B)  =  log  6  -  (1/6)  *  (  2  log  2  +  3  log  3) 

The  calculation  can  be  applied  to  A  and  B,  and  hence  to  any  binary 
tree  decomposition  of  S.  That  is,  if  A  =  E  u  F  and  E  n  F  =  sempty^5,  then 
C(A)  =  C(E  u  F)  =  H(E)  +  H(F)  -  H(A) 

Note  that  H(A)  is  the  same  value  as  in  (*),  and  that  E  and  F  define  a 
set  of  columns  from  all  the  rows  of  the  subset  S.  For  example,  if  E  is 
{1}  and  F  is  {2,3}  then 

H(E)  --  log  6  -  (1/6)  (  5  log  5  ) 

and 

H(F)  -  log  6  -  (1/6)  (  2  log  2  +  3  log  3  ) 

and 

C(A)  =  C(E  u  F)  log  6  -  (1/6)  (  5  log  5  +  2  log  2  ) 

Hence,  an  entropy  loading  value  can  be  computed  for  each  non-terminal 
node  of  a  binary  tree  which  represents  some  partition  of  S. 

Entropy  loading  has  several  properties(van  Emden[vEl]).  The  most 

important  of  these  are 

(1)  C  is  always  non-negative. 

(2)  If  S  =  A  U  B,  A  fl  B  =  <ompty>  and  S  =  EUF,  EflF  =  <ompty> 

and  C(A  U  B)  <  C(E  U  F)  then  A  and  B  interact  less  than  do  E  and  F. 

INTERPRETING  THE  MEASURE 

Intuitively,  entropy  loading  represents  the  extent  to  which 

information  is  shared  between  two  groups  of  objects.  Thus  it 
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characterizes  a  partition  of  the  objects  in  a  program,  given  the 
assumptions  those  objects  make.  As  a  measure  of  structure,  this  means 
that  groups  of  objects  having  small  entropy  loadings  possess  better 
structure  than  other  groups  of  those  objects  having  larger  entropy 
loadings  -  at  least  according  to  the  definition  of  structure  appearing 
in  Chapter  I. 

A  consequence  of  this  property  sometimes  permits  groups  of  objects 
that  share  the  same  number  of  assumptions  to  be  distinguished.  For 
example,  except  for  the  order  of  their  rows,  the  two  tables  below  are 
identical. 


u 

1010 

u 

1010 

V 

0010 

V 

0010 

w 

0110 

z 

1001 

X 

o 

o 

o 

w 

0110 

y 

0001 

X 

0100 

z 

1001 

y 

o 

o 

O 

H(u,v,w,x,y,z) 

H(u,v,w) 

H(x,y,z) 

C(  (u,v,w),  (x,y,z)  ) 

H(u,v,z) 

H(w,x,y) 

C(  (u,v,z),  (w,x,y)  ) 


=  log  6 

=  log  6 

=  log  6  -  (1/3)  log  2 
=  log  6  -  (1/3)  log  2 

=  log  6  -  (1/3)  log  2 

=  log  6  -  (2/3)  log  3 

=  log  6  -  log  2 


Objects  (u,v,w)  share  two  assumptions  with  objects  (x,y,z)  and  (u,v,z) 
share  two  assumptions  with  (w,x,y).  However,  the  entropy  loading  for 
((u,v,z),(w,x,y))  is  less  than  the  entropy  loading  for 
((u,v,w),(x,y,z)).  This  occurs  because  two  assumptions  are  shared  among 
u,  v,  z  and  one  assumption  is  shared  among  w,  x,  y  but  only  one 
assumption  is  shared  among  u,  v,  w  and  only  one  assumption  is  shared 
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among  x,  y,  z.  Thus  entropy  loadings  can  often  distinguish  different 
decompositions  even  though  the  number  of  shared  assumptions  among  the 
subsets  of  each  decomposition  is  the  same. 

In  one  sense,  the  measure  can  also  he  used  to  compare  different 
programs.  Since  a  program  is  regarded  as  a  partitioned  collection  of 
objects,  where  each  object  makes  assumptions,  any  program  represents  a 
system  whose  structure  can  be  measured.  Hence,  comparisons  of  entropy 
loadings  for  two  different  programs  allow  the  structure  implied  by  the 
partitions  of  the  objects  in  each  program  to  be  compared.  Using  the 
measure  to  compare  programs,  however,  does  not  seem  to  be  useful  unless 
the  programs  are  related  in  some  other  way.  For  example,  it  is 
conceivable  that  a  large  program  and  a  small  program  might  be 
partitioned  so  that  their  entropy  loadings  are  approximately  the  same. 
Such  a  comparison  only  indicates  that  the  relative  amounts  of  sharing  in 
each  program,  for  the  selected  partitions,  are  about  the  same. 

Analogously,  a  comparison  of  two  programs  in  terms  of  the  number  of 
statements  each  contains  depends  on  the  way  a  statement  is  defined  for 
each  program.  If  in  one  program  a  statement  is  an  assembly  language 
instruction  and  in  another  a  statement  is  a  FORTRAN  statement,  the 

programs  can  be  compared,  but  the  comparison  may  not  be  very  useful. 
Di  jkst  r  a[DJ  1  in  the  section, "On  Comparing  Programs"]  has  cited  similar 

difficulties  for  other  kinds  of  comparisons  except  where  a  mapping  can 

be  found  that  associates  the  parts  of  the  programs  being  compared.  Such 
a  mapping  can  be  found  if  the  programs  that  are  compared  represent 
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successive  stages  in  the  step-wise  construction  of  a  program.  One  such 
mapping  consists  of  associating  an  object  with  the  objects  into  which  it 

is  refined.  This  mapping  motivates  the  methods  described  in  the  next 
section. 

These  interpretations  of  the  measure  permit  the  definition  of 
entropy  loading  to  be  extended  in  order  to  characterize  a  partition 

containing  more  than  two  sets  of  objects.  If  S  is  partitioned  into  n 

subsets,  s  i ,  S2 . s n  tneri  C  can  be  defined  as 

C(S|,S2,...,sn)  =  (£  i  H(s,))  -  H(S). 

Here,  C  is  non-negative  and  indicates  the  amount  of  sharing  inside  the 
subsets  relative  to  the  amount  of  sharing  among  them.  Note,  however, 

that  just  a  single  figure  characterizes  this  partition.  Further,  there 

seems  to  be  no  useful  relationship  between  the  values  that  result  from 
applications  of  the  original  definition  and  this  extended  one. 

APPLYING  THE  MEASURE  TO  OBJECT/ASSUMPTION  TABLES  FOR  PROGRAMS 

We  propose  to  use  the  measure  to  suggest  ways  of  controlling 

interactions  as  a  program  is  developed.  Elaborations  which  lead  to  high 
entropy  loading  values  at  late  stages  in  the  development  of  a  program 

are  to  be  avoided.  This  is  demonstrated  by  the  examples  in  Chapter  IV. 

We  demonstrate  several  theorems  which  are  relevant  to  fixed  sets  of 
rows  from  a  table.  These  theorems  justify  several  heuristics  which  are 
explained  in  this  chapter  and  used  in  Chapter  IV.  The  fixed  sets  of 

.  . .  . . .  ,  .  _ 


51 


Uni  y. 


A  MEASURE  OF  PROGRAM  STRUCTURE  52 

APPLYING  THE  MEASURE  TO  OBJECT/ASSUMPTION  TABLES  FOR  PROGRAMS 

rows  (the  sets  S  used  in  the  definition  of  the  measure)  will  be  N-th 
stages  in  the  object/assumption  table  for  a  program. 


The  N-th  stage  is  defined  to  be  all  the  objects  whose  <objed 
name>’s  consist  of  N  integers  separated  by  periods  and  those 
objects  whose  names  consist  of  fewer  than  N  integers  but  which 
will  never  be  elaborated. 

Informally,  the  N-th  stages  consist  of  the  terminal  nodes,  at  each 

elaboration,  in  the  map  for  the  development.  For  example,  stage  1  of 
the  development  of  the  gcd  computation  consisted  of  object  :  1 stage  2 
consisted  of  objects  :1.1:  and  :1.2:;  stage  4  consisted  of  :1.1.1.1s, 
:  1 . 1 . 1 .2:,  and  :  1 .2. 1 :.  After  the  theorems  have  been  proved,  several 
heuristics  will  be  staled  for  controlling  interactions  by  usu.g  a 

development  at  stage  N-l  to  suggest  bounds  for  entropy  loadings  at  stage 
N. 


Theorem  1:  Given: 

(1)  a  collection  f  rows  S  =  A  u  B  and 

A  n  B  =  <empty>  where  A  contains  a  rows  and  B 
contains  b  rows; 

(2)  S  makes  assumptions  P  =  C  u  D  and 

C  n  D  =  <empty>; 

(3)  any  row  in  A  makes  assumptions  only  in  C  and  any 
row  in  B  makes  assumptions  only  in  D; 

(4)  a  <  b  and  a  is  as  small  as  possible  for  S, 

subject  to  (1),  (2),  and  (3). 

Conclude: 

C(A  U  B)  achieves  its  minimum  value  for  S  =  A  U  B 

and 

log(a  +  b)  -  l/(a  +  b)  *  (a  log  a  +  b  log  b) 


......  JM*  . 
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Informally,  the  diagram  shows  the  areas  containing  ones  and  possibly 
zeros  as  shaded,  where  A  corresponds  to  some  subset  of  rows  in  S  which 
contains  as  few  rows  as  possible. 

C  0 


A 


B 


Proof: 

H(A)  =  log(a  +  b)  -  <1  /  (a  +  b))  (b  log  b  +  £  ,  a,  log  a,) 

where  £  ,  a,  =  a  and  the  subscripted  a’s  correspond  to  the  partition  of 

A  imposed  by  C.  Similarly 

H(B)  =  log(a  +  b)  -  (1  /  (a  +  b))  (a  log  a  +  £  ;  b,  log  b,) 

where  £  j  bj  =  b  and  the  subscripted  b’s  correspond  to  the  partition  of 

B  imposed  by  D.  Lastly, 

H(A  u  B)  =  log  (a  +  b)  -  (1  /  (a  +  b))  (Z  j  a,  log  aj  +  Z  i  bj  log  bj  ) 
and 

H(A)  +  H(B)  -  H(A  u  B)  =  log  (a  +  b)  -  (1  /  (a  +  b)  (a  log  a  +  b  log  b) 

Now  the  restriction  that  a  be  as  small  as  possible  is  necessary  since 
log(a+b)-(a  log  a  b  log  b)/(a+b)  = 

(a/(a+b))  log((a+b)/a)  +  (b/(a+b))  log{(a+b)/b) 
and  for  a  and  b  positive  integers,  the  right  side  reaches  its  maximum 
when  a  =  b  and  its  minimum  for  the  smallest  a.  Note  that  the  roles  of  a 
and  b  can  be  reversed.// 


. . 
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Consequently,  the  best  decompositions  are  known  for  tables  that 
satisfy  the  conditions  of  the  theorem.  Although  this  theorem  applies 
only  to  an  entire  table,  analogous  results  can  be  obtained  for 
decompositions  of  objects  in  A  as  well  as  B.  Minimal  entropy  loadings 
occur  for  analogous  partitions  of  A  and  B  but  their  values  cannot  be 
derived  directly  from  the  above  theorem.  Another  theorem  states  that 
objects  which  make  identical  assumptions  should  occur  in  the  same  subset 
of  a  partition. 

Theorem  2:  Given: 

(1)  a  collection  of  s  rows,  $  =  A  U  B  and 
A  n  B  =  <empty?  where  A  contains  a  rows  and  B 
contains  b  rows  and  a  +  b  =  s; 

(2)  a  >  b; 

(3)  there  is  a  collection  of  P  rows  which  is  a 

subset  of  S,  containing  p  rows,  p  >  1  and  p  <  s, 
which  make  identical  assumptions; 

(4)  P  n  A  and  P  (1  B  are  both  non-empty; 

Conclude: 

There  exist  A’  and  B’  such  that  A’  U  B’  =  S, 

A’  n  B’  =  <empty>  and  A’  =  A  u  P  and  B’  =  B  -  P  and 

C(  A  U  B  )  >  C(  A’  u  B’  ) 

Proof:  Since  C(A  u  B)  and  C(A’  U  B’)  contain  a  term  which  is  identical, 

namely  H(A  u  B),  if  we  show  that  H(A’)  +  H(B’)  <  H(A)  +  H(B)  then  the 

theorem  is  proved. 

Consider  first  the  expansion  of  H(A),  i.e. 

H(A)  =  log  (a  +  b)  -  ( 1  /(a  +  b))  (R  +  (p  +  t)  log  (p  +  t)) 
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where  R  is  the  sum  of  those  terms  describing  subsets  of  a  partition,  but 
excluding  the  subset  which  contains  the  P  identical  rows.  Here,  p  +  t 
equals  the  number  of  rows  contained  in  the  subset  of  the  partition 
induced  by  A  but  containing  P.  Note  that  t  >  0  and  is  just  the 
difference  between  the  number  of  rows  in  the  subset  of  the  partition 
induced  by  A,  but  containing  P,  and  p. 

Similarly 

H(B)  =  log  (a  +  b)  -  (l/(a  +  b))  (T  +  (p  +  u)  log  (p  +  u)) 
where  T  and  u  play  analogous  roles  to  R  and  t.  Now,  H(A)  »  H(A’)  since 
the  partition  determined  by  A’  is  identical  to  the  partition  determined 

by  A.  But, 

H(B’)  =  log  (a  +  b)  -  ( 1  /(a  +  b))  (T’  +  (p  +  u’)  log  (p  +  u’)). 

We  must  show  that 

( 1  /(a  +  b))  (  T’  +  (p  +  u’)  log  (p  +  u’))  > 

<  1  /(a  +  b))  (  T  +  (p  +  u)  log  (p  +  u)) 

The  two  sides  are  equal  if  the  assumptions  made  by  B’  are  identical  to 
those  made  by  B.  Further,  if  the  assumptions  made  by  B’  are  not  the 
same  as  those  made  by  B,  then  B’  makes  fewer  assumptions  than  B.  In 
this  last  case,  there  are  a  finite  number  of  terms  of  T’  which 

correspond  to  subsets  of  a  partition  with  respect  to  B’  which  contain 

fewer  items  than  the  corresponding  subsets  for  a  partition  with  respect 
to  B.  This  means  that  u’  >  u  and  for  some  finite  number  of  terms  in  T, 
there  are  identical  terms  in  T’  and  there  ore  terms  in  T’  greater  than 

the  corresponding  ones  in  T.  We  then  must  show  that  after  excluding  the 
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identical  terms  in  T  and  T’  that  the  remaining  ierms  in  (*1):  T’  +  (p  + 
u’)  log  (p  +  u’)  are  greater  than  or  equal  to  the  remaining  terms  in 
(*2):  T  +  (p  +  u)  log  (p  +  u).  Denote  by 

Z  i  qj  log  Qi 

the  remaining  terms  in  (*1).  Denote  by 

Z  I  r,  log  rj 

the  remaining  terms  in  (*2),  where 

Z  i  r,  =  Z  i  qi 

Note  that  there  are  fewer  qj’s  than  r j’s  and  that  each  qj  is  the  sum  of 
several  of  the  r j’s  which  correspond  to  the  subset  of  rows  which  qi 
designates.  This  means  that  if 

Z  k  Ck  log  ck  <  <  Z  k  ck  )  log  (  Z  k  ck  ) 

then 


L  i  r,  log  r,<Z  l  di  log  di 

and  the  theorem  is  proved. 


But,  Z  k  ck  log  ck  <  (  Z  k  ck  )  log  (  Z  k  ck  )  since  for  ck  >  1  it 
is  just  the  logarithms  of  both  sides  of  the  inequality 
k  <  ck  T  ck  )  <  <  Z  k  Ck  )  T  (  Z  k  ck) 

(where  "T"  indicates  exponentiation).  // 

Theorem  3:  If  a  set  of  rows  S  satisfies  the  following 

conditions: 

(a)  S  maker,  k  assumptions  (p | ,P2>P3»— »Pk)» 

(b)  S  is  partitioned  into  n  sets  such  that 
there  are  qj  elements  in  the  first,  q2  in  the 
second,...,  qn  in  the  n-th  set,  where  each  set 
is  denoted  by  Sj,  1  <  i  <  n; 
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(d)  pj  is  made  by  Sj,  i  <  j  <  K 

then  the  minimal  entropy  ‘  loadings  are  achieved  for  a 
decomposition  of  the  form 


S| 

— 

1 

s2 

0 

S3 

1 

sn 

Proof:  Assume  that  £  i-i.2t-.n  di  =  M.  The  proof  is  by  induction  on  m 
which  indicates  the  subsets  Sj  of  S.  Observe  that  if  m  =  1 
H(S|)  =  log  M  -  (1/M)  (M  log  M)  =  0 

and  that 

H(  U  Sj  )  =  H(S). 

Hence  C(  S|  U  (  U  Si  ))  =  0,  which  is  the  minimum  value  which 

any  decomposition  could  have.  (Here,  U  means  "the  union  of".)  Assume 
that  for  j  <  m,  the  entropy  loadings  for  the  partition  of  S  indicated  by 


VT';  II  U.l,.  lyiJUfl 
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are  as  small  as  possible.  We  wish  to  show  that  the  entropy  loadings  for 
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are  as  small  as  possible.  Note  that 


H(sm*i)  •=>  log  M  -  (1/M)  (  Z  i-li—»m  Pi  '°2  Pi 

+  (  Z  i-rml>->rt  Pi  )  '°8  (  A.  i*m*i . .  ^ 


and  that 

H(  U  . . .  si  )  =  ^^) 

Suppose  there  is  an  A  and  B  such  that  AuB-U  ,-m . .  P,  and  A  n  B  = 

<empty>  but  that 

(*):  C(A  u  B)  <  C(  s^i  U  (  U  »n  si  )) 

Clearly  a  row  of  sn  makes  all  the  k  assumptions  and  if  at  least  one  row 

of  sn  is  in  A  and  at  least  one  row  of  sn  is  m  B  then 

C(A  u  B)  =  log  M  -  (1/M)  (^  i-b-in  Pi  '°S  Pi  )  > 

C(  Sm*i  u  (  ^  i*m+2 . .  si  ^ 

Hence,  sn  must  be  in  either  B  or  A,  say  B,  and  C(A  u  B)  =  H(A).  But  the 
smallest  such  value  equals  H(sm.,>,  which  contradicts  the  assumption 
(*).  Therefore,  by  the  principle  of  mathematical  induction,  the  theorem 

is  proved.// 


Several  observations  regarding  entropy  loading  can  now  be 
justified: 


(1)  Theorem 
loading  values 
properties,  we 


1  describes  a  situation  for  which  the  best  entropy 
are  known.  If  programs  are  constructed  with  these 
know  how  they  should  be  decomposed. 


(2)  Theorem  2  su8eests  that  objects  which  make  identical 
assumptions  should  occur  in  the  same  portions  of  a  decomposition. 
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(3)  Theorem  3  provides  a  best  decomposition  for  a  situation  where 
different  objects  actually  share  several  assumptions. 

THE  CLUSTERING  PROBLEM 

It  now  seems  reasonable  to  ask  whether  there  are  ways  of  finding  the 
best  decomposition  of  a  given  N-th  stage.  If  this  were  possible,  we 
could  observe  whether  best  decompositions  of  early  stages  are  really 
borne  out  by  a  development.  If  at  any  stage  of  finding  a  best 
decomposition,  the  set  to  be  decomposed  contains  N  items,  then 


Z  . . m[N!  /  (i!  *  (N  -  i)!>  ]  +  X 

(where  m  =  N/2  and  X  is  N!  /  ((N/2)!  *  (N/2)!)  /  2  if  N  is  even  and 
N!  /(  (  N/2  )!  *  (N  -  N/2  )!)  if  N  is  odd) 

partitions  can  be  examined,  and  the  best  entropy  loading  value  and  its 
corresponding  partition  retained.  Except  for  small  N,  this  calculation 
is  intractable.  For  this  reason,  several  authors  have  attempted  to  find 
ways  of  determining  best  decompositions  -  "clusterings"  -  without  having 
to  examine  all  the  partitions.  vanEmden[vEl]  has  mentioned  some  of 
these  methods,  and  has  shown  that  the  most  popular  of  them  are  at  best 
heuristics.  Each  fails  for  trivial  object/assumption  tables. 

Is  it  reasonable  to  look  for  a  tractable  algorithm  which  can  find  a 
best  decomposition?  (The  next  paragraphs  may  be  skipped  at  a  first 
reading.  The  important  result  is  simply  that  an  affirmative  answer  to 
the  question  would  be  very  surprising.) 
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As  of  this  writing,  the  answer  to  the  above  question  is  not  Known. 
However,  a  particular  recognition  problem  provides  evidence  to  suspect 
that  there  is  no  such  tractable  algorithm.  To  describe  this  recognition 
problem,  we  present  several  definitions  and  theorems  due  to  CooK[COO] 
and  Karp[KAl]. 

Definition  1:  P  is  the  class  of  languages  recognizable  by  one-tape 
Turing  machines  which  operate  in  polynomial  time 

Definition  2:  n  is  the  class  of  functions  from  £*  into  £*  defined 
by  one-tape  Turing  machines  which  operate  in  polynomial  time. 

Definition  3:  Let  L  and  M  be  languages.  Then  L  o'  M  (L  is  roducible 
to  M)  if  there  is  a  function  f  (  n  such  that  f(x)  <  M  if  and  only 
if  x  <  L. 

Lemma  1  (Karp):  If  L  <*:  M  and  M  (  P  then  L  (  P. 

Let  P2  denote  the  class  of  subsets  of  x  £,#  which  are 

recognizable  in  polynomial  time.  Given  L2  <  Pz  and  a  polynomial  p,  we 
define  L  as: 

L  =  {x |  there  exists  y  such  that  <x,y>  <L2  and  log(y)  <  p(log(x))} 

L  is  said  to  be  derived  from  L2  by  polynomial-bounded  existential 
quar'  fication  arid  NP  is  the  set  of  languages  derived  from  P2  by 
polynomial-bounded  existential  quantification,  i.e.  NP  can  be  thought 
of  as  the  set  of  languages  which  are  recognizable,  non-deterministically 
in  polynomial  time. 

Now  define  the  satisfiability  problem 

SATISFIABILITY 

INPUT:  cl  and  c2  and  ...  cp  (in  conjunctive  normal  form) 

PROPERTY:  The  conjunction  of  the  given  clauses  is  satisfiable;  i.e. 
there  is  a  set 

S  c  {x|,X2,x3l. . .  )xn;x|,x2,x3,. . .  ,xn} 
such  that 
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(a)  S  does  not  contain  a  complementary  pair  of 
literals 

(b)  S  n  ck  t  <empty>,  k=l,2,...,p. 

Theorem(Cook):  If  L  <  NP  then  L  oc  SATISFIABILITY. 


Corollary:  P  =  NP  if  and  only  if  SATISFIABILITY  (  P. 

Karp  has  shown  that  a  large  number  of  problems  can  play  the  role  of 
SAISFIAB1L1TY  in  the  above  theorem.  Such  problems  are  called  complete 

Definition  4;  The  language  L  is  (polynomial)  complete  if 

a)  L  <  NP 

b)  SATISFIABILITY  u  L 


Theorem  (Karp):  Either  all  complete  languages  are  in  P,  or  none  of  them 
are.  The  former  alternative  holds  if  and  only  if  P  =  NP. 

Theorem  (Karp);  SATISFIABILITY  *  PARTITION  where  PARTITION  is  defined  as 

INPUT:  (c | ,c 2,C3i-  •  •  |Cm)  <  Zm,  positive  integer  m-tuples. 

PROPERTY;  There  is  a  set  1  c  { 1,2,3...  ,m}  such  that  Z  Cj  =  Z  c, 
where  each  i  is  an  element  of  1  and  each  j  is  not  an  element  of  I. 

It  would  be  surprising,  indeed,  if  all  the  complete  problems  were  in  P. 

We  now  show  that  a  recognition  problem  related  to  the  measure  is  at 

least  complete. 

Theorem:  PARTITION  c/  LOG  2  CLUSTERING 

where  LOG  2  CLUSTERING  is  defined  to  be 

INPUT:  a  (0-1)  matrix,  S,  having  N  rows  and  M 
columns. 

PROPERTY:  there  exisls  a  clustering  A  U  B  =  S, 
A  n  B  =  '-'empty>  such  that  C(A  u  B)  =  log  2. 


Proof:  Let  N  =  ^  ,  c. 
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Let  M  =  m 


S[1,J]  = 


r  1.  L  k-l.  .1-1  Ck  <  I  <-  C(,, 

where  an,  upper  bound  for  a  summation  of  0 
equals  0  and  an  upper  bound  greater 
than  N  means  N+l. 


V  0,  otherwise. 

Now,  if  (c i ,c 2. -.Cm)  has  a  partition  with  the  desired  properties  then 
we  choose  as  a  set  A,  all  Ihose  rows  corresponding  to  the  c’s  in  a 
single  set  of  the  par titonj  the  rest  of  the  rows  constituting  B.  Then 


H(A)  =  log  N  -  (1/N)  [l  k  ck  log  ck  ]  -  (1/2)  log  (N/2) 
where  K  is  an  element  of  1. 

H(B)  =  log  N  -  (1/N)  [  l  k  ck  log  ck  ]  -  d/2)  log  fN/2) 
where  k  is  not  an  element  of  1. 

H(A  u  B)  =  log  N  -  (1/N)  [  Z  k  ck  log  ck  +  Z  i  cj  log  cj  ] 
where  k  is  an  element  of  1  but  where  j  is  not  an  element  of  1. 

Hence,  C(A  u  B)  =  log  N  -  log  N/2  =  log  2.  For  all  other  matrices  of 
the  form  described  at  the  beginning  of  the  proof,  there  is  no  partition 
which  leads  to  a  C  value  of  log  2.// 


Intuitively,  this  problem  is  not  as  difficult  as  the  general 
clustering  problem,  yet  a  solution  to  the  clustering  problem,  does  not 
solve  the  partition  problem,  for  the  encoding  above. 
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In  short,  a  tractable  solution  to  the  clustering  problem  would  be 
very  surprising. 

HEURISTICS  FOR  USING  THE  MEASURE 

But  just  a  solution  to  the  clustering  problem  for  an  object/assumption 
table  whose  objects  have  many  interactions  really  is  not  of  much 
interest.  Making  the  best  of  a  bad  design  job  is  not  of  much  interest. 
Programs  should  instead  be  composed  of  ports  which  interact  very  nttle. 
As  programmers,  we  can  modify  the  tables  which  represent  our  programs  in 
order  to  improve  their  structure.  This  is  not  the  case  for  data  in  an 
ecological  study,  for  example,  where  an  object/aosumption  table  is  fixed 
and  a  best  decomposition  might  be  of  interest. 

In  chapter  IV,  the  example  developed  in  chapter  II  wilt  be  examined 
using  of  the  measure.  The  measure  is  used  in  two  ways.  First,  at  early 
stages  in  a  development  the  best  decompositions  are  found.  In  most 
cases  this  is  tractable  because  the  number  of  objects  is  small.  Second, 
if  entropy  loading  figures  for  an  elaboration  ol  the  objects  in  a  best 
decomposition  seem  too  large,  attempts  are  made  to  modify  the 
object/assumption  table  and  the  program  so  that  the  good  properties  of 
the  eartier  decomposition  are  preserved.  The  heuristics  used  are 
summarized  below: 

Assume  we  have  a  decomposition  at  the  N-t h  stage  in  which  the  parts  of 
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the  decomposition  interact  little,  and  that  an  elaboration  has  been  made 
to  the  (N+l)-st  stage. 


(1)  Compute  as  a  rough  lower  bound,  RLB,  for  the  entropy  loading  at 
the  (N+D-st  stage,  the  entropy  loading  with  respect  to  the  N-th 
stage  decomposition,  where  each  object  which  was  elaborated  is 
replaced  by  as  many  new  objects  as  appear  in  the  (N+D-st  stage 
such  that  each  object  makes  NO  assumptions. 

For  example,  if  the  table  below  represents  part  of  a  table  to 
the  N-th  stage  and  at  the  (N+D-st  stage  the  object  X  is 
elaborated  to  three  objects,  we  compute  the  entropy  loadings 
with  respect  to  the  decomposition  at  the  N-th  stage,  but 
replacing  X  by  three  rows  of  zeros. 


X  10  ...  11 


057 

00... 

00... 


stage  N  stage  (N+l) 

This  computation  takes  into  account  the  inci  eased  size  of  the 
table,  but  introduces  new  objects  which  do  not  interact  at  all. 

(2)  As  a  rough  upper  bound,  RUB,  for  the  entropy  loadings  at  the 
(N+D-st  stage,  compute  the  entropy  loadings  with  respect  to  the  N-th 
stage  decompostion  where  each  object  which  was  elaborated  is  replaced  by 
as  many  new  objects  as  appear  in  the  (N+D-st  stage,  such  that  each  new 
object  is  identical  with  its  parent, 

These  guides  are  only  rough  indicators.  The  reader  can  generate  simple 
situations  where  expansions  lead  to  smaller  or  larger  entropy  loading 
values  than  those  indicated,  For  many  cases,  however,  they  are  quite 
useful. 

(3)  Now  compute  the  entropy  loadings  of  the  (N+D-st  stage  and  compare 
its  value  with  RLB  and  RUB.  We  clearly  wish  to  make  each  elaboration  so 
that  the  entropy  loadings  are  as  close  to  RLB  as  possible. 

(4)  If  entropy  loadings  are  greater  than  RUB,  then  several  cases  arise 
which  involve  interactions  resulting  from  one  or  several  of  the 
following 


(a)  new  assumptions  not  appearing  at  the  N-th  stage 

(b)  assumptions  which  appear  at  the  N-th  stage  and  are  shared 
by  the  parents  of  subsets  for  which  RUB  is  exceeded 
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There  are  several  possible  actions 

(a)  Accept  the  interactions  that  are  present  and  proceed  with 
the  development. 

(2)  Attempt  to  localise  the  assumptions  not  appearing  at  the 
N-th  stage  to  a  single  subset  of  the  decomposition  at  the 
(N+ 1  )-st  stage,  Tins  implies  that  a  new  structure,  for  which 
the  new  objects  do  not  have  a  parent,  has  been  imposed  on  the 
(N+l)-st  stage.  An  attempt  should  be  made  to  place  these 
objects  in  some  subset  where,  except  for  the  now  assumptions, 
as  much  mfoi  motion  as  possible  is  shared.  (This  technique  is 
consistent  with  Theorem  2.) 

Chapter  IV  will  display  several  examples  where  this  technique 
can  and  cannot  be  used. 

(3)  Attempt  to  fmd  some  other  decomposition  of  the  objects. 
Hopefully,  such  a  choice  will  result  in  few  changes  in  the 
original  decomposition. 


SATURATION  IN  OBJECT/ASSUMPTION  TABLES 

It  should  be  noted  that  tne  suggestions  in  the  last  section  are 
only  heuristics  which  can  aid  in  evaluating  the  goodness  of  a 
decomposition.  One  situation  winch  occurred  when  several  examples  were 
analyzed  will  be  called  saturation  in  an  object/assumption  table  for  a 
decomposition,  Staled  simply,  this  situation  occurs  whenever  a  table  is 
decomposed  to  a  depth  where  further  attempts  at  decomposing  subsets  of 
certain  objects  results  in  roentical  entropy  loading  values  for  all 
possible  decompositions,  In  a  saturated  table,  the  measure  provides  no 
help  in  distinguishing  decompositions,  Saturation  occurs  moot 

frequently  whenever  a  small  number  of  objects  together  mahe  many 
assumptions.  Frequently,  further  refinements  of  objects  lead  to  tables 
which  are  not  uturated  for  a  decomposition,  This  seems  to  occur 
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whenever  existing  assuniptior  become  localized  to  a  small  number  of 
objects  relative  to  the  total  number  at  a  given  stage.  Examples  of  this 
situation  are  cited  in  the  next  chapter.  Saturation  indicates  bad 
structure  in  the  sense  that  all  the  objects  at  a  particular  stage  share 
much  information. 

ON  THE  PROBABILITY  OF  CHANGE  OF  ASSUMPTIONS 

The  examples  in  Chapter  II  indicate  that  objects  make  many 
assumptions  even  in  small  programs,  Yet,  some  of  the  assumptions  are 
never  likely  to  change  even  after  major  modifications  of  the  program. 
Intuitively,  these  assumptions  seem  to  have  less  influence  on  the 
structure  of  a  program  from  one  modification  to  the  next  than  do 
assumptions  which  are  very  likely  to  change.  Theorems  from  mathematics 
have  already  been  cited  as  assumptions  which  can  never  be  wrong  and 
hence  have  zero  probability  of  change.  However,  assumptions  based  on 
say  "the  position  of  information  in  a  control  block",  which  have  a  very 
high  probability  of  change,  have  a  great  influence  on  structure  from 
modification  to  modification,  Theoretically,  every  assumption  could  be 
rated  with  a  probability  of  change,  even  if  that  rating  is  simply  a 
relative  one,  eg.  that  one  set  of  assumptions  has  a  greater 

probability  of  change  than  another. 

In  this  section,  we  extend  the  measure  to  take  into  account  a 
probability  of  change  for  each  assumption.  This  extension  is  shown  to 
be  consistent  with  the  definition  of  entropy  loading. 


. . . -  • 
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First,  note  the  property: 

If  an  assumption,  say  X,  is  shared  by  every  (no)  row  in  some  set  of 
rows  then  for  any  decomposition  of  that  set,  the  entropy  loadings 
computed  when  considering  X  are  identical  with  the  entropy  loadings 
computed  when  not  considering  X. 

Proof:  Just  observe  that  any  partition  determined  by  a  set  of 
assumptions  ot her  than  X  is  not  changed  if  X  is  added  to  the  set  of 
assumptions. 

Next,  observe  that  no  matter  how  many  objects  make  assumptions  which  can 
never  change  or  regardless  of  where  those  assumptions  are  made,  t here 
will  be  no  ill  effects  because  of  those  assumptions,  should  the  program 

ever  be  changed.  For  this  reason,  unchanging  information  can  be 
distributed  without  affecting  the  ease  of  either  maintainence  or  change. 

However,  these  assumptions  are  relevant  to  understanding  the  program  and 
should  be  listed  in  a  specification  or  at  least  in  the  object/assumption 
table.  Consequently,  we  modify  the  entropy  loading  calculation  so  that 
it  remains  consistent  with  the  properties  stated  at  the  beginning  of  the 
chapter,  but  allows  assumptions  which  are  certain  to  change  (probability 
of  change  -  1)  to  have  the  same  effects  as  before  and  permits 

assumptions  which  will  never  change  to  exert  no  effects.  The 

modification  also  has  the  property  that  it  can  be  computed  for  any  set 
of  assumptions  having  any  probability  of  change  values  associated  with 
each  assumption. 
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The  only  change  involves  the  way  H(X)  is  computed.  As  before, 

H(X)  =  log  N  -  (1/N)  Z  i  n,  log  nj 

=  Z  i  <n|  /N)  log  (N/ni)  (*) 

where  the  n,’s  correspond  to  the  number  of  rows  in  each  subset  of  a 
partition  imposed  by  the  assumptions  of  X  on  the  N  rows.  (*)  above  is 
the  standard  definition  of  entropy  from  information  theory  -  and  has  all 
its  properties  -  if  we  interpret  n,/N  as  a  probability  so  long  as 

Z  ,  (nj  /N)  =  1. 

From  this  point  of  view,  n,  need  not  be  an  integer.  Instead,  we  compute 
the  nj’s  as  follows. 


(1)  Choose  a  function  of  one  variable,  f,  defined  on  the  closed 

interval  [0,1]  such  that  f(x)  >  x  and  f  is  strictly  monotonic  (such 
a  function  is  just  the  probability  of  change  itself). 

(2)  Construct  a  new  table  as  follow  •*. 

(a)  fill  the  table  with  those  columns  from  the  original  table 

whose  probability  of  change  is  1  and  associate  with  each  of 

the  N  rows  a  value,  w,  =  1  for  the  i-th  row.  (if  the  table 

has  no  such  columns,  create  a  new  table  with  N  rows,  w,  =  1, 
kj  =  i  and  containing  a  single  column  each  entry  of  wteich 
equals  1) 

So  long  as  there  are  assumptions  which  allow  (b)  to  be 

executed,  repeat  (b),  (c),  and  (d). 

(b)  Select  a  single  assumption,  say  P  with  probability  of 

change  p,  from  those  that  remain  (ignoring  all  assumptions 
whose  probability  of  change  equals  zero),  attach  this  column 

to  the  new  table,  and  select  the  value  of  the  parameter,  rt,  as 

follows: 

if  the  number  of  occurrences  of  "1"  is  less  than  N/2  in 

the  column  for  P,  then  let  n  be  1;  otherwise  0. 


(c)  for  each  row  of  the  table  which  does  not  contain  an  entry 
for  assumption  P.  say  j,  choose  its  entry  to  be  identical  with 
the  entry  for  P  in  row  i,  1  <  i  <  N,  such  that  k,  =  kj.  (this 
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step  will  not  need  to  be  performed  the  first  time  (b)  is 
executed) 

(d)  For  each  row  in  the  new  table,  say  i,  which  has  an  entry 
for  P  which  equals  n,  add  a  new  row,  j,  to  the  table  which  is 
identical  to  row  i  except  that  the  entry  for  P  is  1  -  n  and 
set  wj  to  w,  -  f(p)  *  w,  and  Wj  equal  to  f(p)  *  w,. 

(3)  Now  for  each  pattern  of  l’s  and  0’s,  sum  the  respective  w’s  to 
get  a  set  of  sj’s  and  compute  H(X)  as 

H(X)  =  Z  i  (sj/N)  log  (N/sj)  as  H(X) 

The  result  of  this  computation  is  independent  of  the  order  in  which  the 
assumptions  are  used  in  the  algorithm.  The  value  is  consistent  with  the 
observations  stated  earlier.  The  improvements  of  Chapter  IV  will  use 
these  ideas  as  a  primary  justification  for  ignoring  certain  assumptions. 

An  example  of  this  computation  is  indicated  by  the  table  below: 


1  .5  .25 
0  1  1 
1  0  1 
1  1  0 
1  0  1 
0  0  1 

where  the  value  above  each  column  represents  the  probability  of  change 
of  the  assumption  associated  with  that  column  (this  value  will  be  used 
as  f). 


After  step  (a),  the  new  table  is 


k  w  1 

1  1  0 

2  1  1 

3  1  1 

4  1  1 

5  1  0 
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After  selecting  a  remaining  assumption,  and  executing  b 

n  -  1  and 

k  w  1  .5 

110  1 
2  110 

3  111 

4  110 

5  10  0 

(c)  need  not  be  executed,  but  after  (d),  the  table  is 

k  w  1  .5 

1  .5  0  1 

2  110 

3  .5  1  1 

4  110 

5  10  0 

1  .5  0  0 

3  .5  1  0 

Next,  (b)  is  executed  leaving  n  -  0  and  the  table 

k  w  1  .5  .25 

1  .5  0  1  1 

2  110  1 

3  .5  1  1  0 

4  1  1  0  i 

5  10  0  1 

1  .5  0  0 

3  .5  1  0 

After  executing  (c),  the  table  is 


k  w  1  .5  .25 

1  .5  0  1  1 

2  110  1 

3  .5  1  1  0 

4  110  1 

5  10  0  1 

1  .5  0  0  1 

3  .5  1  0  0 
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Lastly,  after  executing  (d)  the  table  Is 

k  w  1  .5  .25 

1  .5  011 

2  1  10  1 

3  .125  1  1  0 

4  1  10  1 

5  1  0  0  1 

1  .5  0  0  1 

3  .125  1  0  0 

3  .375  1  1  1 

3  .375  1  0  1 


Hence,  H  for  this  table  can  be  computed  from 


011  .5 

101  2.375 

110  .125 

001  1.5 

100  .125 

111  .375 


The  effect  of  this  calculation  has  been  to  modify  the  influences  of 
assumptions  whenever  entropy  loading  calculations  are  computed. 
Consequently,  this  same  calculation  can  be  used  to  modify  the  influences 
of  assumptions  for  other  properties  besides  "probability  of  change". 
For  example,  if  the  relation  "importance  of  assumptions"  can  be 
established  for  a  program,  this  modified  calculation  can  be  used. 


. . - Hi .  Ill  _ 


CHAPTER  IV 


USING  THE  MEASURE 

The  heuristics  described  in  Chapter  III  which  provide  suggested 
bounds  for  entropy  loading  values  are  used  as  guides  to  control 
interactions  between  the  parts  of  a  decomposition.  Entropy  loading 
values  for  various  decompostions  of  the  example  from  Chapter  II  are 
displayed.  In  addition,  several  other  examples  are  developed  using  the 
measure  as  a  guide. 

INTRODUCTION 

Chapters  I  and  II  provided  a  definition  of  program  structure  along 
with  techniques  for  preserving  assumptions  which  help  to  determine 
structure.  Chapter  III  described  a  numerical  calculation  -  entropy 
loading  -  which  can  use  these  assumptions  to  compare  the  "goodness  of 
different  guesses  at  what  the  components  of  a  decomposition  of  a  program 
are.  The  theorems  in  Chapter  III  form  the  basis  for  methods  of 
constructing  elaborations  for  components  in  an  initial  decomposition. 
These  methods  are  used  to  insure  that  components  interact  little  in  the 
final  program,  either  by  verifying  the  presence  of  reasonable 
interactions  or  by  indicating  that  elaborations  which  interact  less 
should  be  sought.  Such  programs  have  a  good  chance  of  satisfying  the 
properties  stated  in  the  Introduction  to  this  thesis. 


.... - 
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These  methods  are  first  demonstrated  with  respect  to  the  GCD 
example  from  Chapter  ii. 


A  GCD  COMPUTATION 

Despite  the  small  size  of  the  GCD  program,  entropy  loading 
calculations  cai  be  used  to  show  that  certain  decompositions  of  the 
objects  have  greater  interactions  between  their  parts  than  others.  (For 
the  following  discus;  ion,  it  is  assumed  that  the  probability  of  change 
of  all  assumptions  is  one,  i.e.  that  all  assumpt  jns  are  likely  to 
change  and  have  potentially  the  same  influence  on  structure.)  Below  is 
the  object/assumption  table  for  the  GCD  computation  from  Chapter  II. 
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0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 

B  symbolizes  the  initial  value  in  b 

3)  write  access  to  x  is  required 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

6)  a  =  gcd(A.B) 

7)  (a  =  b)  a  gcd(A,B)  =  gcd(a,b)  ^  a  =  gcd(A,B) 

8)  x  =  a  ^  x  =  gcd(A,B) 

9)  a  =  gcd(A,B)  =>  true 


...  ..  .  . 
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10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

12)  a’  and  b'  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1.1.2: 

13)  «(a<a’  v  b<b’)  A  gcd(a,b)=gcd(A,B)  a  a/b)  ? 

(a^b  a  gcd(a,b)  =  gcd(A,B))  a  maxU'^b’)  >  max(a,b)) 

1A)  g-d(a,b)  =  gcd(A,B) 

15)  a  ^  b 

16)  [{gcd(a,b)=gcd(A,B))3 

(gcd(a’,b,)=gcd(a,b))  holds  prior  to  executing  :1. 1.1. 2.1:)]  and 
[(gcd(a\b’)=gcd(a,b),  holds  after  executing  :1 . 1 . 1 .2. 1  :)=> 
(gcd(a,b)=gcd(A,B))] 

17)  gcd(a,b)  =  gcd(a’,b’) 

18)  (a  >  b  a  gcd(a’,b’)  =  gcd(a-b,b)  v 
a  <  b  a  gcd(a’,b’)  =  gcd(a,b-a) 

19)  gcd(a’,b’)  =  gcd(a-b,b) 

20)  gcd(a’,b’)  =  gcd{a,b-a) 

21)  gcd(a’,b’)  =  gcd(a,b-a)  true, 

b  decreased  by  a  ^  gcd(a’,b’)  =  gcd(a,b) 

22)  gcd(a’.b’)  =  gcd(a-b,b)  ^  true, 

a  decreased  by  b  s  gcd(a,b)  =  gcd(a’,b’) 

The  map  for  the  development  is 

A  GCD  COMPUTATION 


:1:  (pg-  31) 

:  1 . 1 :  (32)  :1.2:  (32) 

I  I 

,1.1.1:  (34)  ,1.2.1:  (34) 

(x  «-  a) 


:1. 1.1.1:  (36) 
(while  a  t  b  do 
:1. 1.1.2:;) 


:1. 1.1.2:  (36) 


:1.1. 1.2.1;  (37) 


:1. 1.1.2. 1.1:  (39)  :  1 . 1 . 1 .2. 1 .2:  (39)  :1. 1.1.2. 
(  if  a  >  b  then 
:1. 1.1.2. 1.2: 
else 

:1 .1.1.2. 1.3:  ;) 


.3:  (39) 


:1. 1.1. 2.1. 2.1:  (41)  :  1 . 1 . 1 .2. 1 .3. 1 :  (Al) 
(a  <-  a  -  b)  (b  <-  b  -  a) 


— — - - 


hHMMi 
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Object  :1:  assumes  that  positive  integer  values  are  contained  in 
variables  a  and  b  and  has  the  effect  of  assigning  to  x  the  value  of  the 
greatest  common  divisor  of  the  initial  contents  of  a  and  b  (symbolized 
by  A  and  B,  respectively). 

Object  :1.1:  leaves  the  value  of  gcd(a,b)  in  a  and  object  : i .2 :  assigns 
the  value  of  a  to  x. 

The  theorem  that  (gcd(a,b)  =  gcd(A,B)  a  a  =  b)  a  a  =  gcd(A,B)  is  hidden 
from  il.l.l:  and  a  =  gcd(A,B)  is  hidden  from  :  1 .2. 1 

Object  :  1 . 1.1.1:  controls  the  execution  of  :  1 . 1.1.2:  which  maintains  the 
invariant  (a  <  a’  v  b  <  b’)  a  gcd(a,b)  =  gcd(A,B),  where  a’  and  b’  are 
tl  3  values  of  a  and  b  prior  to  each  iteration. 

Object  :  1 . 1.1. 2.1:  hides  the  invariant  gcd(a,b)  =  gcd(A,B) 

Finally,  objects  :1. 1.1. 2.1.1:,  :1. 1.1. 2.1. 2:,  and  il.l.l. 2. 1.3: 

implement  a  conditional  statement  which  results  in  (a  <  a’  v  b  <  b’)  A 
gcd(a,b)  =  gcd(a’,b’). 

Not  surprisingly,  the  best  [  1  ]  decomposition  for  the  development 

represented  by  the  terminal  nodes  of  the  tree 

:  1 : 

:  1 .2: 

I 

: 1 .2. 1 : 


:  (:1. 1.1.1:,  :1. 1.1.2:)  (while  a  i  b 
so  that  gcd(a,b)  =  gcd(A,B)  )  and 

( :  1 .2. 1 :)  (  x  «-  a  ) 


:  1 . 1 : 


il.l.l: 


:1.1.1.1s 


.1.1. 1.2: 


is  a  decomposition  into  two  parts 
do  ...  ,  decrease  a,  b  or  both 


[1]  Of  two  decompositions  for  the  same  objects,  one  decomposition  is 
said  to  be  "better"  than  another  if,  starting  at  the  root,  a  difference 
in  entropy  loading  values  is  found  at  some  node  and  that  decomposition 
has  the  smaller  entropy  loading  value  a*  that  node.  Clearly,  this 
comparison  is  only  meaningful  for  decompositions  which  are  based  on 
trees  which  have  the  same  shape  to  the  stage  where  they  are  compared. 


. . . 
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with  entropy  loading  value  .637[i?]  which  is  identical  with  the  values  of 
the  rough  lower  bound  (RLB)  and  rough  upper  bound  (RUB)  tor  the 
expansion  from 


:1: 


sl.l: 

l 

:1.2: 

1 

1 

:  1 . 1 . 1 : 

• 

: 1 .2. 1 : 

This 

indicates  that  the 

assignment 

of  a  to  x  interacts 

least. 

Similarly,  after  refining 

:1. 1.1.2:  to 

:1.1. 1.2.1:  the  entropy 

loading 

of 

(:1. 1.1.1:,:1. 1.1.2  1:) 

and  (:  1 .2. 1 :) 

is  again  equal  to 

.637. 

Refinements  of  :1. 1.1.2. 1:,  however,  show  that  RLB  and  RUB  are  indeed 
"rough"  bounds  since  for  (:1. 1.1.1:,  :1. 1.1. 2.1:)  and  <:  1 .2. 1  •).  RLB  is 

.951  and  RUB  is  1.33,  but  the  actual  entropy  loading  for  (*): 
(:  1.1. 1.1:,  :1.1. 1.2.1. 1:,  :1. 1.12.1  2:,  :l. 1.1.2.13:1  and  <:1.2.1:) 

is  .500,  indicating  that  the  distribution  of  the  increased  number  of 
assumptions  in  the  new  table  causes  less  mte'action  between  the  two 
subsets  of  the  partition.  The  best  decompos  hon  of  (*)  appears  below, 
with  the  entropy  loading  values  at  each  non-termmal  node 


[2]  The  numerical  values  representing  entropy  loadings  are  all  computed 
with  respect  to  natural  logarithms  and  not  logarithms  to  the  base  2. 
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However,  the  refinements  of  1.1. 1.2. 1.2:  and  :1. 1.1. 2.1.3:  lead  to  a 
program  whose  best  decomposition  is 

(A) 

.  .500  -  .500 

:  1.2.1:  >  950  or  :1.2.1:  \  .950 

:1. 1.1. 2. 1.2.1:  \  .673 


:1. 1.1. 2. 1.3.1:  '  ,.673 

A 


:1. 1.1. 2. 1.3.1:  (:1. 1.1.1:, 

:1.1. 1.2.1. 1:) 

Further,  the  decomposition 


:1. 1.1. 2. 1.2.1: 


(:1. 1.1.1:, 

:1.1. 1.2.1. 1:) 


(B) 


.500 


: 1.2. 1 : 

(-.1.1. 1.1:,  il.1.1.2.1.1:) 

is  better  than 


>  1.05 

(:1. 1.1. 2.1. 2.1:,  :  1 . 1 . 1 .2. 1 .3. 1 ) 


(C) 


.500 


: 1 .2. 1 : 
il.l.l.l:^ 
:1. 1. 1.2.1. 1:' 


A 


1.33 


\  1.05 


( :  1 . 1 . 1.2. 1.2.1:, 

:1. 1.1.2. 1.3.1:) 


In  particular,  the  best  decomposition  before  the  last  refinement  is  not 
the  best  decomposition  after  the  refinement.  The  reasons  for  this 
result  are  obvious  from  an  examination  of  the  ibject/assumption  table 
(in  the  light  of  the  above  calculations,  but  are,  perhaps,  not  so 
obvious  without  them).  The  assumptions  made  by  :1, 1.1.2. 1.2:  (decrease 
a  by  b)  and  :1. 1.1.2. 1.3:  (decrease  b  by  a  )  are  more  numerous  than  for 
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their  refinements.  These  additional  assumptions  increase  the  number  of 
subsets  in  the  partitions  which  determine  the  H  values,  but  do  so  in  a 
way  which  indicates  little  relative  interaction  among  the  subsets  of  the 
decomposition.  However,  since  the  final  refinement  involves  few 
assumptions,  there  is  greater  relative  interaction  for  the  same 
decomposition.  From  the  standpoint  of  interactions  alone,  the  best 
decompositions  are  indicated  in  (A),  and  in  a  larger,  but  similar, 
example  vvork  assignments  might  be  made  based  upon  these  decompositions. 
This  decot, 'position  separates  the  actions  of  assigning  values  to 
variables  from  the  mechanisms  which  control  these  operations.  Hence, 
the  measure  indicates  that  the  control  mechanisms  interact  most  since 
they  require  more  information  about  the  program  However,  should  a 
designer  wish  to  distribute  more  information,  in  the  form  of  assumptions 
at  earlier  stages,  the  decompositions  in  (B)  or  (C)  might  be  more 
appropriate. 

A  different  elaboration  of  this  version  might  arise  by  observing 
that  for  each  execution  of  the  body  of  the  loop,  two  tests  are  made  for 
each  modification  of  either  a  or  b, 
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GCD  Computation  (Version  II) 

:1.1. 1.2.1:  (80) 

(decrease  a,  b  or  both 
so  that  gcd(a,b)  =  gcd(A,B)  ) 


:1. 1.1  2.1.1:  (81)  :  1. 1. 1.2.1. 2:  (82) 

/  \  I  \ 

(c)  :1.1.1.2.1. 1.1:  (d)  :1. 1.1. 2.i.  1.2:  (e)  :  1 . 1 . 1 .2. 1 .2. 1 :  «)  :  1 . 1 . 1 . 2. 1 .2. 2 : 


(while  a  >  b  do  )  (84) 

(84) 


(while  b  >  a  do  ) 
(85) 


(85) 


<g):l.  1.1. 2.1. 1.2.1:  (87) 
(a  <-  a  -  b) 


(h):l.  1.1 .2. 1.2.2.1  :(87) 

(  b  «-  b  -  a  ) 


The  development  of  this  version  is  identical  with  the  development  in 
Chapter  II  up  to  :  1 . 1.1. 2.1:.  Version  I  maintains  the  invariant 

gcd(a,b)  =  gcd(a’,b’)  but  version  II  requires  that  a  or  b  or  both  have 

been  modified  more  than  once,  if  possible. 

Object  :1. 1.1. 2.1.1:  decreases  a  until  it  oecomes  smaller  than  b,  but 
maintains  the  invariant  gcd(a,b)  =  gcd(a’,b’). 

Object  :1. 1.1.2. 1.2'  makes  b  smaller  than  a,  but  maintains  the  invariant 
gcd(a,b)  =  gcd(a’,b'). 

Objects  :1. 1.1. 2.1.1:  and  :1. 1.1. 2. 1.2.1:  are  while  constructions  that 

control  :1. 1.1. 2. 1.1. 2:  and  :  1. 1 . 1.2. 1.2. 2:  respectively. 

Lastly,  :1. 1.1. 2. 1.1. 2.1:  and  :  1. 1.1. 2.1. 2.2.1:  are  elaborations  from 

which  are  hidden  information  about  the  invariants  that  are  being 

maintained. 
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A  new  elaboration  of  :1. 1.1.2:  might  be 


:1.1. 1.2.1: 

assumptions:  neither  multiplication  nor  division  is  to  be  used 

and  a  >  0,  b  >  0,  a  and  b  are  integer  variables,  A 
symbolizes  the  initial  value  of  a  and  B  symbolizes 

the  initial  value  of  b,  a  is  an  integer  variable, 

read  and  write  access  is  required  for  both  a  and  b, 

a’  and  b’  equal  the  respective  values  of  a  and  b 

prior  to  the  last  execution  of  :1. 1.1.2:,  gcd(a,b)  = 
gcd(A,B)  s  gcd(a\b’)  =  gcd(a.b),  F  - 

gcdfa’.b’),  :  1 . 1 . 1.2.1:  is  the  body  of  a  loop  which 

makes  the  test  "a  t1  b" 

:1.1. 1.2.1:  DECREASE  EITHER  a,  b,  OR  BOTH  a  AND  b 

SUCH  THAT  gcd(a,b)  =  gcdts’.b’)  WHERE  a  OR  b  HAVE 
BEEN  MODIFIED  MORE  THAN  ONCE,  IF  POSSIBLE. 

effects  and 

post-condition:  (a  <  a’  or  b  <  b’),  gcd(a.b)  =  gcd(a’,b’),  if- 

possible,  more  than  one  modification  of  a  or  b 

should  occur  for  each  test  of  the  outer  loop. 
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The  best  decomposition  for  the  three  objects  is 
(01.2.1 :)  (:1. 1.1.1:,  :1.1 .1.2.1:))  .637  [1] 

:1. 1.1. 2.1:  is  elaborated  next 

:1. 1.1. 2.1.1: 

assumptions:  a>OAb>OAa  and  b  are  integer  variable, 

write  access  to  a  is  required,  read  access  to  a  is 
required,  read  access  to  b  is  required,  a’  and  b’ 
equal  the  respective  values  of  a  and  b  prior  to  the 
last  execution  of  :1. 1.1.2:,  gccl(a,b)  =  gcd(a’,b’), 

:1. 1.1. 2.1:  is  the  body  of  a  loop  which  makes  the 
test  "a  y  b",  neither  multiplication  nor  division  is 
to  be  used 

:1.1. 1.2.1. 1:  IF  POSSIBLE,  MAKE  a  SMALLER  THAN  b 
SUCH  THAT  gcdfa.b)  =  gcd(a’,b’) 

effects  and 

post-condition:  a  <  a’  a  gcd(a,b)  =  gr.d(a’,b’)  a  a’>b’  3  b’>a 


[1]  This  notation  will  be  used  instead  of  tree  diagrams  to  indicate  a 
decomposition  and  the  entropy  loading  values  for  non-terminal  nodes. 
(The  value  of  an  instance  of  <number>  represents  the  entropy  loading 
value  for  the  parenthesized  pair  to  its  left.) 

<decomposition>  ::=  (  <part  list>  <part  list>  )  <number>  | 

(  <part  list>  <part  lisl>  ) 

<part  list>  :;=  <decomposition>  |  <simple  part  list> 

<simple  pari  list''  ::=  <object  name>  | 

<simple  part  list>  ,  <object  name> 


USING  THE  MEASURE 
A  GCD  COMPUTATION 


82 


: 1 . 1 .1.2. 1.2: 

assumptions: 


effects  and 
post-condition: 

verification: 


a>0Ab>0Aa  and  b  are  integer  variables,  read 
access  to  a  is  required,  write  access  to  b  is 
required,  read  access  to  b  is  required,  a’  and  b’ 
equal  the  respective  values  of  a  and  b  prior  to  the 
last  execution  of  :1. 1.1.2:,  gcd(a,b)  =  gcdfa’.b’), 
neither  multiplication  nor  division  is  to  be  used 
:  1 . 1.1. 2.1:  is  the  body  of  a  loop  which  makes  the 
test  "a  /  b" 

:1. 1.1. 2.1.2:  IF  POSSIBLE,  MAKE  b  SMALLER  THAN  a 
SUCH  THAT  gcd(a,b)=gcd(a’,b’> 


gcd(a,b)  =  gcd(a’,b’)  a  b<b’  a  (b’  >  a  3  a  >  b) 

To  show  that  the  post-condition  for  :  1 . 1.1. 2.1: 
h-..w.s,  i.e.  (a  <  a’  v  b  <  b’}  a  gcd(a,b)  = 
gcd(a’,b’),  if  possible,  more  than  one  modification 
of  a  or  b  should  occur  for  each  test  of  the  outer 
loop,  holds. 

Case  1:  if  a’  >  b’  then  b  >  a  and  a  <  a',  since 
after  the  execution  of  :1. 1.1. 2.1.2:,  gcd(a,b;  = 
gccKa’.b'). 

Case  2:  If  b’  >  a  then  a  >  b  which  means  that  b’  > 
b.  But  since  gcd(a,b)  =  gcd(a',b’)  the 

post-condition  holds 

if  more  than  one  modification  of  either  a  or  b  can 
be  made,  this  elaboration  will  make  more  than  one 
such  modification. 
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The  relevant  table  is  then 

0  123456789  10  III  2 13 14 1 5 1 6 1 7 1 8 
i  l  •  t ■  1-2-  1  :  II  II  III  I  II 

:  l  •  i  •  1-2-  l  •  l i  ii  ii  II  II 

:  I  •  I ■  I  •  2-  1  •  2:  II  I  III  II 

0)  neither  multiplication  nor  division  is  to  be  used 

I)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

II)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1.1.2: 

17)  gcd(a,b)  =  gcd(a\b’) 

18)  :1. 1.1. 2.1:  is  the  body  of  a 

loop  which  makes  the  test  "a  ^  b" 

RLB  and  RUB  for  this  expansion  both  equal  1.04,  but  the  best 
decomposition  has  better  entropy  loading  values  than  RLB  and  RUB  would 
suggest,  and  is  derived  from  the  last  stage,  i.e. 


((:  1 .2. 1 :)  ((:1. 1.1.1:)  (:1.1. 1.2.1. 1:,  :1. 1.1.2.1.2:))  1.38)  .562 
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Expanding  :1. 1.1. 2.1.1:  and  :  1.1. 1.2.1.2:  gives 


(c)  :1.1. 1.2.1. 1.1: 

assumptions:  a  >  0  a  b  >  0  a  a  and  b  are  integer  variables,  read 

access  to  a  is  required,  read  access  to  b  is 

required,  a1  and  b’  equal  the  respective  values  of  a 
and  b  prior  to  the  last  execution  of  :1.1.1.2:, 

gcd(a.b)  =  gcd(a',b’),  gcd(a’,b’)  a  a  >  b  ^ 

gcd(a’,b’)  =  gcd(a-b,b),  neither  multiplication  nor 
division  is  to  be  used 

:1 . 1 . 1.2. 1.1.1:  while  a  >  b  do 

(d)  :1.1. 1.2.1. 1.2: 

assumptions:  a>0Ab->0Aa  and  b  are  integer  variables, 

write  access  to  a  is  required,  read  access  to  a  is 
required,  read  access  to  b  is  required,  a  and  b 

equal  the  respective  values  of  a  and  b  prior  to  the 
last  execution  of  :  1 . 1 . 1 .2:,  gcd(a,b)  =  gcd(a  ,b  ), 

gcd(a’,b’)  =  gcd(a-b,b),  neither  multiplication  nor 

division  is  to  be  used 

:1.1. 1.2.1. 1.2:  DECREASE  a  BY  b 

•fleet  and 

post-condition:  a  has  been  decreased  by  b. 

a  >  0  a  b  >  0  a  a  and  b  are  integer  variables, 
gcd(a’,b’)  =  gcd(a,b) 


effect  and 
post-condition: 
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Similarly,  we  elaborate  :1. 1.1. 2. 1.2: 

(e)  :1. 1.1. 2.1. 2.1: 

assumptions:  a>0Ab>0Aa  and  b  are  integer  variables,  read 

access  to  a  is  required,  read  access  to  b  is 

required,  a’  and  b’  equal  the  respective  values  of  a 
and  b  prior  to  the  last  execution  of  :1. 1.1.2:, 

gcd(a,b)  =  gcd(a’,b’),  (gcd(a,b’)  A  b  >  a)  ^ 

gcd(a’,b’)  =gcd(a,b-a),  neither  multiplication  nor 

division  is  to  be  used. 

:  1. 1.1.2. 1.2. 1:  while  b  >  a  do 

(f)  :1. 1.1.2. 1.2.2: 

assumptions:  a>0Ab>0Aa  and  b  are  integer  variables,  read 

access  to  a  is  required,  write  access  to  b  is 

required,  read  access  to  b  is  required,  a’  and  b’ 
equal  the  respective  values  of  a  and  b  prior  to  the 
last  execution  of  :1. 1.1.2:,  gcd(a,b)  =  gcd(a’,b’), 

gcd(a’,b’)  =  gcd(a,b-a),  neither  multiplication  nor 
division  is  to  be  used 

:1. 1.1. 2.1.2. 2:  DECREASE  b  BY  a 

effect  and 

post-condition:  b  has  been  decreased  by  a 

effects  and 

post-condtion:  a>0Ab>0Aa  and  b  are  integer  variables, 

gcd(a,b)  =  gcd(a’.b’) 
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The  table  for  these  two  parts  is  then 

0123456789  101112131415161718192021222324 

(c )  : i •  i  •  i  •  2  •  l  •  l  •  i 1  i  l  i  11  1  1 

(d)  :  i  •  i  -  i  •  2-  l  •  l  •  2:  li  li  11  i  1 

(e)  :  i .  i  •  i  •  2-  l-  2-  l:  ll  l  li  1  1 

(f)  :  i-  l-  1-  2-  l-  2-  2:  ll  i  ill  1  1 

0)  neither  multiplication  nor  division  is  to  be  used 

I)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

II)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1.1.2: 

17)  gcd(a,b)  =  gcd(a’,b’) 

19)  gcd(a’,b’)  =  gcd(a-b,b) 

20)  gcd(a’,b’)  =  gcd(a.b-a) 

23)  (gcd(a\b’)  a  a  >  b)  3  gcd(a’,b’)  =  gcd(a-b,b) 

24)  (gcd(a’,b’)  a  b  >  a)  =>  gcd(a\b’>  =  gcd(a,  b-a) 


For 

((:  1 .2. 1 :)  ((:1.1.1.1:)(:1.1. 1.2.1. 1 1 . 1 . 1 .2. 1 .2:))  *1)  *2 

RLB  is  *1  =  .868 
RUB  is  *1  =  ,451  and  *2  =  .868 
but  the  actual  loadings  for  the  above  elaboration  are 

«:  1.2.1)  <(:1. 1.1.1:)  <(  c  ,  d  )  <  e  ,  f  ))  1.33)  .868)  .451 
Here  the  inner  loops  appear  in  two  distinct  subsets.  It  should  be  noted 
that  if  the  while  constructions  appear  together  the  entropy  loading 
figures  do  not  change,  i.e.  (  (  c  ,  e  )  (  d  ,  f  ))  1.33.  Further, 

((  c  )  (  d  ,  e  ,  «  ))  1.24 

This  is  the  same  entropy  loading  value  for  all  other  decompostitions  of 
c,  d,  e,  and  f  where  one  subset  contains  just  a  single  object. 

Lastly,  the  assignments  can  be  elaborated  if  we  add  assumptions  to  the 


table  as  follows 
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0123456789  1011 12 1314 1516 1 7 1819202 1 22 
(d)  ■  I  •  I  •  I  •  2-  I  •  I  •  2*  I  II  II  I  I  * 

(0  :  1  •  1  •  1  •  2  1  •  2  2:  1  I  III  I  I  * 

0)  neither  multiplication  nor  division  is  to  be  used 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1.1.2: 

17)  gcd(a,b)  =  gcd(a’,b’) 

19)  gcd(a’,b’)  =  gcd(a-b,b) 

20)  gcd(a’,b’)  =  gcd(a,b-a) 

21)  gcd(a’,b’)  =  gcc)(a,b-a)  3  true, 

b  decreased  by  a  3  gcd(a’,b’)  =  gcd(a,b) 

22)  gcd(a\b’)  =  gcd(a-b,b)  o  true, 

a  decreased  by  b  3  gcd(a,b)  =  gcd(a’,b’) 

(g)  :1.1. 1.2.1. 1.2.1: 

assumptions:  write  access  to  a  is  required,  read  access  to  a  is 

required,  read  access  to  b  is  required 

:1.1. 1.2.1  1.2.1:  a  «-  a  -  b. 

effects  and 

post-condition:  a  decreased  by  b 

and 

(h)  :1. 1.1. 2. 1.2. 2.1: 

assumptions:  read  access  to  a  is  required,  write  access  to  b  is 

required,  read  access  to  b  is  required 

:1. 1.1.2. 1.2.2. 1:  b  <-  b  -  a. 

effects  and 

post-condition:  b  decreised  by  a 

Now,  note  the  following  entropy  loading  calculations,  where  a  names 
:  1 .2. 1 :  and  b  names  :1. 1.1.1:, 

(A):  ((a)  ((b)  ((  c  ,  g)  (  e  ,  h  ))  1.79  )  1.33  )  .451 

but  that 


(B):  ((a)  ((b)  ((  c  ,  e  )  (  g  ,  h  ))  1.01  )  1.33  )  .451 
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and 

(C):  ((a)  ((  g  ,  h  )  ((b)  (  c  ,  e  )>  1.01  )  1.01)  .451 
(A)  corresponds  to  a  decomposition  which  is  based  on  the  best 
decomposition  at  the  last  stage.  Both  (B)  and  (C)  are  better 

decompositions  for  the  program  representation  from  which  several 
assumptions  are  hidden.  (B)  corresponds  to  the  situation  in  version  1 
where  control  mechanisms  appear  together.  Here  c  and  e  represent  the 
two  inner  while  constructions,  (C)  indicates  that  the  objects  which 
assign  values  to  x,  a  and  b  interact  with  the  program  less  than  the 

control  mechanisms. 


USING  THE  MEASURE 
A  GCD  COMPUTATION 


89 


A  final  version  of  the  progran  can  be  elaborated,  in  much  the  same  way 
as  above,  but  where  even  more  assumptions  are  made  by  the  objects. 
Specifically: 


Compute  the  value  of  the  greatest  common  divisor  of  the 
initial(positive)  contents  of  the  integer  variables  a  and  b,  and  leave 
the  result  in  the  variable  x;  also  leave  in  the  variable  y  the  value  of 
the  least  common  multiple  of  a  and  b,  i.e.  a*b  /  gcd(a,b),  but  without 
using  either  multiplication  or  division. 

A  GCD  Computation  (Version  III) 

:1:  (90) 


:1.2:  (91) 


:  1 . 1 :  (91) 


.’1.1.1:  (93)  (a)  :1.2.1:  (93) 

(x  «-  a) 


(b)  :1.1.1.0s  (96)  (c)  sl.l.l.l:  (95)  (d)  :1. 1.1.2:  (95) 
(c  «-  0;  d  «-  a)  (while  a  +  b  do  ...) 


(e)  :1.1. 1.2.1:  (98)  (f):l.  1.1.2  2:  (98) 


(g)  :1.1. 1.2.1. 1:  (h)  :1.1.1. 2.1.2:  (i):1.1.1.2.2.1:  (j)  :1.1.1.2.2.2 
(while  a  >  b  do  )  (100)  (while  b  >  a  do  ) 

(100)  I  (ion 


(101) 


(K)  : 1.1. 1.2. 1.2.1: 

(a  «-  a  -  b;  d  *-  d  +  c) 
(105) 


(I)  :1. 1.1.2. 2.2.1: 

(b  «-  b  -  a;  c  *-  c  +  d) 
(105) 


This  development  is  essentially  identical  with  version  II  except  that 

the  least  common  multiple  (Icm)  of  the  initial  contents  of  a  and  b  is 

computed  in  addition  to  the  gcd  of  these  values. 

:1:  states  the  problem,  *.1.1:  has  the  effect  of  leaving  c+d  =  A*B/ 
gcd(A,B)  anJ  a  =  gcd(A,B). 

:1 .2:  assigns  x  the  value  of  gcd(A,B)  and  y  the  value  of  lcm(A,B)  The 

relationships  c  +  d  *»  lcm(A,B)  and  a  =  gcd(A,B)  are  hidden  from  :  1 .2. 1 
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Object  :1  1.1.0:  was  introduced  to  initialize  c  and  d  so  that  the 
invariant  A*6  =  a*c+b*d  holds,  prior  to  the  execution  of 
:1. 1.1.1:. 

The  remainder  of  the  tree  is  the  same  as  the  co  responding  objects  in 
version  11  except  that  the  invariant  A*B  =  a*c  +  b*dis  maintained 
in  addition  to  gcd(A.B)  «  gcd(a.b). 

:1: 


assumptions:  neither  multiplication  nor  division  is  to  be  used 

and  a  >  0,  b  >  0,  A  symbolizes  the  initial  value  of 
a,  B  symbolize'  the  initial  value  of  b,  a  is  an 
integer  variable,  b  is  an  integer  variable,  write 
access  to  x  is  required,  write  access  to  y  is 
required,  neither  multiplication  nor  division  is  to 
be  used  :1:  COMPUTE  THE  GCD  AND  THE  LCM  OF  a  AND  b, 
LEAVE  THE  GCD  IN  THE  VARIABLE  x  AND  THE  LCM  IN  THE 
VARIABLE  y. 


effects  and 

post-condition:  x  =  gccl(A,B)  a  y  =  lcm(A.B) 

verification:  Since  the  gcd  and  Icm  of  any  two  positive  integers 

are  always  defined  and  are  computable,  the 
computation  is  feasible. 


The  object/assumption  table  for  :1:  is 


0  |  2  3  4  5  6/89  10 III 2 13 14 1 b 1 61 7 1 81 9202 1 22232425 
:  i :  i  i  i  l  i  i  ii  1 

0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
B  symbolizes  the  initial  value  in  b 

3)  write  access  to  x  is  required 
A)  write  access  to  a  is  required 
5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 
25)  write  access  to  y  is  required 
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We  elaborate  :1:  as 

:1.1: 

assumptions:  neither  multiplication  nor  division  is  to  be  used 

and  a  >  0,  b  >  0,  A  symbolizes  the  initial  value  of 
a,  B  symbolizes  ihe  initial  value  of  b,  a  is  an 
integer  variable,  b  is  an  integer  variable,  write 
access  to  a  is  required,  write  access  is  required 
for  c,  write  access  is  required  for  d,  c  and  d  are 
integer  variables,  neither  multiplication  nor 
division  is  to  be  used,  (a=b  a  gcd(A.B)  =  gcd(a,b)  a 

a*c  +  b*d  =  A*B)  =>  a  =  gcd(A,B)  a  c  +  d  =  lcm(A,B) 

:1.1:  REPLACE  THE  VALUE  OF  a  BV  gcd(A.B)  AND  LEAVE 
THE  EXPRESSION  c  +  d  EQUAL  TO  lcm(A.B) 

effects  and 

post-condition:  a  -  gcd(A,B)  a  c  +  d  -  lcm(A,B) 

:  1.2: 

assumptions:  a  -  gcd(A,B),  write  access  to  x  is  required,  read 

access  to  a  is  required,  c  and  d  are  integer 

variables  ,  c  +  d  =  lcm(A,B),  write  access  to  y  is 
required,  read  access  is  required  for  both  c  and  d, 
neither  multiplication  nor  division  is  to  be  used 

:  1 .2:  REPLACE  THE  VALUE  OF  x  BV  THE  VALUE  CONTAINED 
IN  a  AND  THE  VALUE  OF  y  BY  c  +  d. 

effects:  x  =  a  a  y  =  lcm(A,B) 

post-condition:  x  =  gcd(A  B) 

verification:  In  order  for  x  =  gcd(A,B)  and  y  =  lcm(A,B)  to  hold 

after  :  1 .2:,  given  that  its  effect  is  x  =  a  and  y  = 
c  +  d,  its  assumptions  must  be  a  -  gcd(A,B)  and  c  + 
d  =  lcm(A,B).  But  this  is  guaranteed  as  the 
post-condition  of  :l.l:.  Further,  :1.1:  requires 
the  same  assumptions  as  :  1 :  plus  the  ability  to 
store  into  a. 
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object/assumption  table  for  :  1 . 1 :i.2: 

0123456789  101112131415161718192021222324252627282930 

:  1 .  1 :  i  l  l  l  i  l  •  >  1  11 

ill 

:  1 .  2*.  i  i  i  i 

0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
B  symbolizes  the  initial  value  in  b 

3)  write  access  to  x  is  required 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

6)  a  «=  gcd(A,B) 

7)  (a=b  a  gcd(a,b)=gcd(A,B)  a  a*c+b*d=A*B)  ^ 

(a=gcd(A,B)  A  c+d=lcm(A,B)) 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

25)  write  access  to  y  is  required 

26)  c  and  d  are  integer  variables 

27)  read  access  is  required  tor  both  c  and  d 

28)  c  +  d  =  lcm(A,B) 

29)  write  access  is  required  for  c 

30)  write  access  is  required  for  d 
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Next  an  elaboration  of  :1.1:  can  be  made  by  hiding 

(a=b  a  gcd(a,b)=gcd(A,B)  A  a*c+b*d>  A*B)  o 
(a=gcd(A,B)  a  c+d=lcm(A,B)) 

(This  has  already  appeared  as  an  assumption  for  :  1 . 1 :.) 

assumptions:  neither  multiplication  nor  division  is  to  be  used 

and  a  >  0,  b  >  0,  A  symbolizes  the  initial  value  of 
a,  B  symbolizes  the  initial  value  of  b,  a  is  an 
integer  variable,  b  is  an  integer  variable,  read  and 
write  access  is  required  for  both  a  and  b,  c  and  d 
are  integer  variables  ,  read  access  is  required  for 
both  c  and  d,  write  access  >s  required  for  c,  write 
access  is  required  for  d,  neither  multiplication  nor 
division  is  to  be  used 

si.  1.1:  MAKE  a  =  b  SUCH  THAT  gcd(a,b)  =  gcd(A,B)  AND 
c  AND  d  SUCH  THAT  a*c  +  b*d  =  A*B. 

effects  and 

post-condition:  a  =  b,  gcdfa.b)  =  gcd(A,B)  a  a*c  +  b*d  =  A*B 


An  elaboration  of  :  1.2:  can  be  made  if  we  observe  that 


(a  =  gcd(A.B)  a  c+d  =  lcm(A,B))  =>  true 
(x  =  a  a  y  =  c  +  d)  o  (x  =  gcd(A,B)  a  y  =  lcm(A.B)) 


But  since  :1.2:  assumes  a  =  gcd(A,B)  we  can  write 


(a)  :1 .2.1: 

assumptions:  write  access  to  x  is  required,  read  access  to  a  is 

required,  write  access  to  y  is  required,  c  and  d  are 
integer  variables  ,  read  access  is  required  for  both 
c  and  d,  neither  multiplication  nor  division  is  to 
be  used 


:  1.2.1 :  x  <-  aj  y  «-  c  +  d; 


effect  and 
post-condition: 


x=a,  y=c  +  d 
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As  a  result,  the  object/assumption  table  for  :1.1,  :1.2:,  rl.1.1:,  and 
: 1 .2. 1 :  is 


I  •  l: 
I  •  2" 


(a) 


1-2-  !  • 


0123456789  101 1 12I3I415I6I7 1 8 1 9202 1 22232A25262 7 2  82930 
I  I  I  I  I  li  III 

I  I  I  I  ♦  *  III 

I  I  I  I  I  II  III 


I 


I 


0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  Integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
8  symbolizes  the  initial  value  in  b 

3)  write  access  to  x  is  required 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

6)  a  =  gcd(A,B) 

8)  (a  =  gcd(A,B)  a  c+d  =  lcm(A,B))  =  true 

9)  (x  =  a  a  y  =  c  +  d)  a  <x  =  gcd{A,B)  A  y  «=  lcm(A,B)) 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

25)  write  access  to  y  is  required 

26)  c  and  d  are  integer  variables 

27)  read  access  is  required  for  both  c  and  d 

28)  c  +  d  =  lcm<A,B) 

29)  write  access  is  required  for  c 

30)  write  access  is  required  for  d 
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Adopting  the  convention  that  a’  a'd  b’  equal  the  values  of  a  and  b  just 
prior  to  the  most  recent  execution  of  :  1 . 1 . 1.2:  we  elaborate  il.l.l: 

(c)  :1. 1.1.1: 

assumptions:  neither  multiplication  nor  division  is  to  be  used 

and  a  >  0,  b  >  0,  A  symbolizes  the  initial  value  of 
a,  B  symbolizes  the  initial  value  of  b,  a  is  an 

integer  variable,  t>  is  an  integer  variable,  read 
access  is  required  for  both  a  and  b,  a’  and  b’  equal 
the  respective  values  of  a  and  b  prior  to  the  last 
execution  of  :  1 . 1 . 1 .2:,  [((a  <  a’  v  b  <  b’)  a 

gcd(a,b)  =  gcd{A,B)  Aa^b)^(a^bA  gcd(a,b)  = 
gcd(a\b’))  A  max{a’,b’)  >  max(a,b»],  c  and  d  are 
integer  variables,  a*c  +  b*d  =  A*B,  neither 

multiplication  nor  division  is  to  be  used 

:1. 1.1.1:  while  a  /  b  do  :1. 1.1.2:  ; 

post-coridition:  a  =  b,  gcd(a,b)  =  gcd(A,B),  c  +  d  =  lcm(A,B) 

(d)  il.l.l. 2: 

assumptions:  neither  multiplication  nor  division  is  to  be  used 

and  a  >  0,  b  >  0,  A  symbolizes  the  initial  value  of 

a,  B  symbolizes  the  initial  value  of  b,  a  is  an 
integer  variable,  b  is  an  integer  variable,  read  and 
write  access  is  required  for  both  a  and  b,  a’  and  b’ 
equal  the  respective  values  of  a  and  b  prior  to  the 
last  execution  of  il.l.l. 2:,  a  ^  b,  gcd(a,b) 
gcd{A,B),  write  access  is  required  for  c,  write 

access  is  required  for  d,  read  access  is  required 

for  both  c  and  d,  c  and  d  are  integer  variables  , 

a*c  +  b*d  =  A*B,  neither  multiplication  nor  division 

is  to  be  used 

il.l.l. 2:  DECREASE  EITHER  a,  b,  OR  BOTH  a  AND  b  SUCH 
THAT  gcd(a,b)  =  gcd(A,B)  AND  INCREASE  c,  d  OR  30TH 
SUCH  THAT  a*c  +  b*d  =  A*B. 

effect  and 

post-condition:  (a  <  a’  v  b  <  b’),  gcd(a,b)  =  gcd(A,B) 


. :r-’r'"  -  - .- - - - —  - — -v> 
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Note  that  the  condition  a*c  +  b*d  -  A*B  cannot  be  guaranteed  since  no 
values  have  been  assigned  to  c  or  to  d  and  since  no  previous  part  of  the 
program  has  guaranteed  this  condition.  Hence,  :1. 1.1.0:  is  introduced 
as 


(b)  :1. 1.1.0: 

assumptions:  c  and  d  are  integer  var  ables,  write  access  is 

required  for  c,  write  access  is  required  for  d,  A  » 
a  a  B  =  b,  read  access  to  a  is  required,  read  access 
to  b  is  required,  neither  multiplication  nor 
division  is  to  be  used  and  a  >  0,  b  >  0,  a  and  b  are 
integer  variables,  A  and  B  symbolize  the  respective 
initial  values  of  a  and  b,  neither  multipliction  nor 
division  is  to  be  used 

:l.l.i.O:  ASSIGN  VALUES  TO  c  AND  d  SUCH  THAT  a*c  ; 
b*d  -  A*B,  i.e.  c  <-  0;  d  «-  a; 


effects:  c  -  0  a  d  >  a 

post-condition:  a*c  *  b*d  =  A*B 

verification:  Since  A  =  a  and  B  =  b  and  c  =  0  and  d  ■  a  then  a  *  c 

♦  b*d  =  a*b. 


Here  the  statement  of  :1. 1.1.0:  also  includes  its 
own  elaboration.  Most  of  the  assumptions  for 
:i.  1.1.0:  could  be  hidden  from  an  elaboration  which 
would  read  "ASSIGN  i  HO  TO  c  AND  THE  VALUE  OF  a  TO 
d". 


i 
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The  object/assumption  table  is  then: 

0123456789  101 1 12I314151G171 819202 1 2223242526272829303  1 32 

(b)  :  i-  i-  i-o*  ill  I  I  1  III 

(c)  :  | .  i .  |.  | :  i  i  i  i  i  l  l  l  I  I 

(d)  :  i-  i-  i-  z{  ill  ii  ill  ii  11  111 

0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
B  symbolizes  the  initial  value  in  b 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1.1.2: 

13)  (((a<a’  v  b<b’)  a  gcd(a,b)=gcd(A,B)  a  a^b)  ^ 

(a^b  a  gcd(a.b)  ■=  gcd(A,B))  A  max(a\b’)  >  max(a,b)) 

14)  gcd(a.b)  -  gcd(A,B) 

15)  a  ^  b 

25)  write  access  to  y  is  required 

26)  c  and  d  are  integer  variables 

27)  read  access  is  required  for  both  c  and  d 

29)  write  access  is  required  for  c 

30)  write  access  is  required  for  d 

31)  a*c  +  b*d  =  A*B 

32)  A  «=  a  a  B  =  b 


Because  of  the  large  number  of  assumptions  made  by  a,  b,  c,  and  d  all 
possible  decompositions  have  the  same  entropy  loading  values.  This  is 
an  instance  of  saturation  in  a  table.  The  decomposition  which  was  best 
for  the  previous  developments  cf  this  program  at  this  stage  is 


((a)  ((b)  (  c  ,  d  ))  1.39  )  1.39 
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We  add  the  following  assumption  to  :1. 1.1.2: 

gcd(a’,b’)  =  gcd(a.b)  s  gcd(a.b)  =  gcd(A,B) 

(e)  :1.1. 1.2.1: 

assumptions:  a->0Ab>0Aa  and  b  are  integer  variables,  A 

symbolizes  the  initial  value  in  a  and  B  symbolizes 
the  initial  value  in  b  write  access  to  a  is 

required,  read  access  to  a  is  required,  read  access 
to  b  is  required,  a’  and  b’  equal  the  respective 

valuer  of  a  and  b  prior  to  the  last  execution  of 
:  1,1.1. 2:,  gcd(a,b>  =  gcdfa’.b’),  c  and  d  are 

integer  variables  ,  read  access  is  required  for  both 
c  and  d,  write  access  is  required  for  c,  write 
access  is  required  for  d,  a*c  +  b*d  =  A*B,  neither 

multiplication  nor  division  is  to  be  used 

:  1.1.1. 2.1:  IF  POSSIBLE,  MAKE  a  SMALLER  THAN  b  SUCH 
THAT  gcd(a,b)  =  gcd(a’.b’)  AND  MAKE  c  AND  d  SUCH 
THAT  a*c  +  b*d  =  A*B. 

effects  and 

post-condition:  a  <  a’  a  gcd<a,b)  =  gcdfa’.b’)  a  a’>b’  3  b’>a  a  a*c 

+  b*d  =  A*d 

(f)  :1.1. 1.2.2: 


assumptions:  a  >  0  a  b  >  0  a  a  and  b  are  integer  variables,  A 

symbolizes  the  initial  value  in  a  and  B  symbolizes 
the  initial  value  in  b  read  access  to  a  is  required, 

write  access  to  b  is  required,  read  access  to  b  is 
required,  a’  and  b’  equal  the  respective  values  of  a 
and  b  prior  to  the  last  execution  of  :1. 1.1.2:, 

gcdfa.b)  =  gcd(a’,b’),  c  and  d  are  integer  variables 
,  read  access  is  required  for  both  c  and  d,  write 
access  is  required  for  c,  write  access  is  required 

for  d,  a*c  +  b*d  =  A*B,  neither  multiplication  nor 

division  is  to  be  used 

:1. 1.1. 2.2:  IF  POSSIBLE,  MAKE  b  SMALLER  THAN  a  SUCH 
THAT  gcd(a,b)=gcd(a’,b’)  AND  MAKE  c  AND  d  SUCH  THAT 
a*c  +b*d  =  A*B. 

effects  and 

post-condition:  gcdfa.b)  =  gcd(a’,b’)  a  b<b’  a  (b1  >  a  =>  a  >  b) 

verification:  To  show  that  the  post-condition  for  :1. 1.1.2:  holds, 

i.e.  (a  <  a’  v  b  <  b’)  a  gcd(a.b)  =  gcd(a’,b’)  a*c 
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,v  b*d  =  A*B,  holds.  Case  1:  if  a’  >  b’  then  b  >  a 
and  a  <  a’,  since  after  the  execution  of 

:1. 1.1. 2.1. 2:,  gcd(a,b)  =  gcd(a’,b’). 

Case  2:  If  b’  >  a  then  a  >  b  which  means  that  b’  > 
b.  But  since  gcd(a,b)  =  gcd(a’,b’)  the 

post-condition  holds.  For  both  cases,  a*c  +  b*d  = 

A*B  also  holds. 

The  relevant  table  is  then 

0  I  23456789  101 1 121314151617 1 8 1 9202 1 2223242526272S29303 1 
(•)  •  I*  |.  I •  2*  Is  III  II  II  I  11  111 

(f)  S 1  •  I  •  1-2-  2*  III  I  111  I  I  I  I  I 

0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
B  symbolizes  the  initial  value  in  b 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :i. 1.1.2: 

25)  write  access  to  y  is  required 

26)  c  and  d  are  integer  variables 

27)  read  access  is  required  for  both  c  and  d 

29)  write  access  is  required  for  c 

30)  write  access  is  required  for  d 

31)  a*c  +  b*d  =  A*B 

32)  A  =  a  a  B  =  b 

RLB  is  (  (a)  ((b)  (  c  ,  d  ))  .950  )  .950 
RUB  is  (  (a)  ((b)  (  c  ,  d  ))  1.33  )  1.33 
Unfortunately,  the  actual  values  are 

((a)  ((b)  ((c)  (  e  ,  f  »  1.61  )  1.61  )  1.33 
This  is  also  a  best  decomposition.  One  reason  for  this  increase  in 
entropy  loadings  is  because  more  assumptions  are  shared  among  the 


objects. 
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We  elaborate  :  1 . 1 . 1 

(g)  :1.1. 1.2.1. 1: 

assumptions: 


(h)  :1. 1.1. 2. 1.2: 
assumptions: 


effects  and 
post-conditions: 


.2.1:  as 


a  >  0  a  b  >  0  a  a  and  b  are  integer  variables,  A 
symbolizes  the  initial  value  in  a  and  B  symbolizes 

the  initial  value  in  b  read  access  to  a  is  required, 

read  access  to  b  is  required,  a’  and  b’  equal  the 

respective  values  of  a  and  b  prior  to  the  last 

execution  of  :  1 . 1 . 1 .2:,  gcd(a,b)  =  gcd(a  ,b  ), 

gcd(a’,b’)  a  a  >  b  =  gcd(a’,b’)  «=  gcd(a-b.b),  c  and 
d  are  integer  variables  ,  a*c  +  b*d  ■  A*B,  neither 
multiplication  no-'  division  is  to  be  used 

:  1 . 1 . 1.2.1. 1:  while  a  >  b  do 


a  >  0  a  b  >  0  a  a  and  b  are  integer  variables,  A 
symbolizes  the  initial  value  in  a  and  B  symbolizes 
the  initial  value  in  b  write  access  to  a  is 

required,  read  access  to  a  is  required,  read  access 
to  b  is  required,  a’  and  b’  equal  the  respective 
values  of  a  and  b  prior  to  the  last  execution  of 
:1. 1.1.2:,  gcd(a.b)  =  gcd(a\b’),  gcd<a\b’) 

gcd(a-b.b)  a  A*B  -  (a-b)*c  +  b*(d+c),  c  and  d  are 
integer  variables  ,  a*c  +  b*d  =  A*B,  read  access  is 
required  for  both  c  and  d,  write  access  is  required 
for  d,  neither  multiplication  nor  division  is  to  be 

used 

:l. 1.1. 2.1.2:  DECREASE  a  BY  b  AND  INCREASE  d  BY  c. 

a  has  been  decreased  by  b  and  d  has  been  increased 
by  c 


a  >  0  a  b  >  0  a  a  and  b  are  integer  variables, 
gcd{a’,b’)  =  gcd(a,b),  a*c  +  b*d  =  A*B 


-i 


effect  and 
post-contition: 
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Similarly,  we  elaborate  :1.1. 1.2.2: 

(i)  :1. 1.1. 2.2.1: 

assumptions:  a>0Ab>0Aa  and  b  are  integer  variables,  A 

symbolizes  the  initial  value  in  a  «nd  B  symbolizes 

the  initial  value  in  b  read  access  to  a  is  required, 

read  access  to  b  is  required,  a’  and  b’  equal  the 

respective  values  of  a  and  b  prior  to  the  last 
execution  of  :1. 1.1.2:,  gcd(a,b)  =  gcd(a’,b’), 

(gcd(a.b’)  a  b  >  a)  3  gcd(a’.b’)  =gcd(a,b-a),  c  and 
d  are  integer  variables  ,  a*c  +  b*d  ■  A*B,  neither 
multiplication  nor  division  is  to  be  used 

:1. 1.1. 2. 2.1:  while  b  >  a  do 

(j)  :1. 1.1. 2.2. 2: 

assumptions:  a>0Ab>0Aa  and  b  are  integer  variables,  A 

symbolizes  the  initial  value  in  a  and  B  symbolizes 

the  initial  value  in  b  read  access  to  a  is  required, 
write  access  to  b  is  required,  read  access  to  b  is 
required,  a’  and  b’  equal  the  respective  values  of  a 
and  b  prior  to  the  last  execution  of  :1.1.1.2:, 
gcd(a.b)  =  gcd(a’,b’),  gcd(a’,b’)  =  gcd(a,b-a)  a  A*B 

=  a*(c+d)  +  <b-a)*d,  c  and  d  are  integer  variables, 
a*c  +  b*d  =  A*B,  read  access  is  required  for  both  c 
and  d,  write  access  is  required  for  c,  neither 
multiplication  nor  division  is  to  be  used 

:1. 1.1.2.2  2:  DECREASE  b  BY  a  AND  INCREASE  c  BY  d; 

effects  and 

post-conditions:  b  has  been  decreased  by  a  and  c  has  been  increased 

by  d 


a>0Ab>0Aa  and  b  are  integer  variables, 
gcd<a,b)  =  gcd(a’,b’)  a  a*c  +  b*d  =  A*Q 


effects  and 
post-condition: 
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The  table 

for  these  two 

0  l  2 

(g)  •  i-  i- 

1-2-  1  •  1 :  1  1  1 

(h) 

1-2-  1-  2:  1  1  1 

(i)  *•  i  i- 

1  •  2-  2-  1 :  1  1  1 

(j)  :  i •  1  • 

1  •  2  2  2-  1  1  1 

l 

l  l 
l 


I  l 
l  l 
l  t 
i  l  l 


l 

I  i 
I 

i  i 


i  I 


0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  m  a  and 
B  symbolizes  the  initial  value  in  b 

A)  write  access  to  a  is  required 
5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

11)  tead  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1.1.2: 

17)  gcdta.b)  =  gccKa’.b’) 

19)  i',cd(a\b’)  =  gcd(a-b.b)  a  A*B  =  (a-b)*c  +  b*(d+c) 

20)  gcd(a’.b’)  =  gcd(a,b-a)  a  A*B  =  a*(c+d)  +  (b-a)*d 

23)  (gcd(a’.b’)  a  a  >  b  a  a*c  +  b*d  =  A*B)  3  gcd(a\b’)  =  gcd(a-b.b)  a  A*B  =  (a-b)*c 
■»  b+(d+c)  ) 

24)  (gcd(a\b’)  a  b  >  a  a  a*c  ♦  b*d  =  A*B  )  =>  gcd(a\b’)  -  gcd(a,  b-a)  a  a*c  ♦  b*d  « 
A*B 

25)  write  access  to  y  is  required 

26)  c  and  d  are  integer  variables 

27)  read  access  is  required  for  both  c  and  d 

28)  c  +  d  =  lcm(A,Bl 

29)  write  access  is  required  for  c 

30)  write  access  is  required  for  d 

31)  a*c  +  b*d  =  A*B 


▲ 
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RLB  and  RUB  from 

((a)  ((b)  ((c)  (  •  ,  f  )))) 

for  the  above  expansion  are 

RLB:  ((a;  ((b)  ((c)  (  e  ,  f  )))  .796  )  .796 
RUB:  ((a)  ((b)  ((c)  (•,!))  1.55  )  1.55  )  1.54 
The  actual  entropy  loading  values  are 

((a)  ((b)  ((c)  (  g  ,  h  ,  i  ,  j  ))  1.48  )  1.75  )  1.28 
which  is  again  a  best  decomposition.  If  (  g  ,  h  ,  i,  j  ) 
the  best  decomposition  is 

((  g  ,  i  )  (  h  ,  j  »  1.55 
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is  decomposed, 


which  indicates  that  the  bodies  of  the  two  loops  interact  less  with  the 
control  mechanisms  for  those  loops  than  do  the  loops  with  each  other. 
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Lastly,  the  assignments  can  be  elaborater  if  we  add  assumptions  to  the 
table  as  follows 


0  I  2  14  5  6  7  8  9  toil  1213141516171?’ '-><'02122232425262728293031 
(K)  :  |.  |.  |.  2-  I-  2:  I  I  I  I  I  11  !  I  4  II  I  1 

(I)  i  I •  l ■  I ■  2-  2-  2*  I  l  I  I  I  I  I  1  1  *  11  1  1 

0)  neither  multiplication  nor  division  is  to  be  used 

I)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

10)  write  access  to  b  is  required 

II)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1.1.2: 

17)  gcd(a.b)  *=  gcd(a’,b’) 

19)  gcd(a\b’)  =  gcd(a-b.b) 

20)  gcd(a’,b’)  **  gcd(a.b-a) 

21)  (gcd(a\b’)  *>  gcd(a.b-a)  a  A*B  =  (a-b)*c  +  b*(d+c)  )  o  true, 
b  decreased  by  a  ^  gcd!a’,b’)  ■  gcd(a,b) 

22)  (gcd(a’,b’)  =  gcd(a-b.b)  a  A*B  =  a*{r+d)  +  (b-s)*d)  =  true, 
a  decreased  by  b  ^  gcd(a,b)  =  gcd(a  ,b  i 

23)  (gcd(a’.b')  a  a  >  b  a  a*c  +  b*d  =  A*B)  ^  gcd(a’,b’)  =  gcd(a-b,b)  a 
A*B  =  (a-b)*c  +  b*(d+c)  ) 

24)  (gcd(a’,b’)  a  b  >  a  a  a*c  +  b*d  ■  A*B  )  =  gcdfa’.b’)  **  gcd(a,  b-a)  A 
a*c  +  b*d  =  A*B 

25)  write  access  to  y  is  required 

26)  c  and  d  are  integer  variables 

27)  read  access  is  required  for  both  c  and  d 

28)  c  +  d  =  lcm(A,B) 

29)  write  access  is  required  for  c 

30)  write  access  is  required  for  d 

31)  a*c  +  b*d  =  A*B 
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(k)  2. 1.2.1: 

assumptions:  '//rite  access  to  a  is  required,  read  access  to  a  is 

required,  read  access  to  b  is  required  read  access 
is  required  for  both  c  and  d,  write  access  is 
required  for  d,  neither  multiplication  nor  division 
is  to  be  used 

:1. 1.1. 2. 1.2.1:  a  a  -  b;  d  ♦-  d  +  c; 

effects  and 

post-condition:  a  decreased  by  b  and  d  increased  by  c. 


0)  :1.1.1. 2. 2. 2.1: 

assumptions:  read  access  to  a  is  required,  write  access  to  b  is 

required,  read  access  to  b  is  required  read  access 
is  required  for  both  c  and  d,  write  access  is 
required  for  c,  neither  multiplication  nor  division 
is  to  be  used 

:1. 1.1. 2.2. 2.1:  b  ♦-  b  -  a;  c  ♦-  c  +  d; 

effects  and 

post-condition:  b  decreased  by  a  and  c  increased  by  d 
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Now  we  can  display  the  table  for  this  new  development. 


i: 

0  1 

2  3  4  5  6 

lilt 

l  i: 

I-  2: 

• 

1 

1 

1  1  1 

1  1 

(a) 

I-  1 

!•  2’ 

• 

1 

1 

1  1  1 

1  1 

(b) 

1-  1 

•  0* 

1 

1  1 

(0 

I-  1  • 

I-  b 

1 

1  1 

(d) 

I-  1  • 

1 •  2« 

1 

1  1  1 

(e) 

I-  1' 

1-2-  1  * 

1 

1  1  1 

(f) 

l-  1  ■ 

1  2-  2' 

1 

1  1 

<B> 

1  •  1- 

I-  2  !•  1  • 

1 

1  1 

(h) 

I-  1  • 

1  ■  2-  I-  2- 

1 

1  1  1 

(i) 

1'  b 

1  2-  2  l: 

1 

1  1 

(j) 

1-  1 

I-  2-  2  2* 

1 

1  1 

(K) 

I-  b 

1-2  12 

i:  1 

1  1 

(1) 

12  2  2 

i:  1 

1 

3  4  5  6  7  8  9  10 1 1 1 2 13 141 5 1 6 1 7 1 81 9202 1 2223242526272829303 1 32 


I 


I  I 


I 


I  I 

I  I 

I  I  I 


I  I  I 

I  I  I 

I  I 


I  I 

I  I 
I  I 


0)  neither  multiplication  nor  division  is  to  be  used 

1)  a  >  0,  b  >  0,  a  and  b  are  integer  variables 

2)  A  symbolizes  the  initial  value  in  a  and 
B  symbolizes  the  initial  value  in  b 

3)  write  access  to  x  is  required 

4)  write  access  to  a  is  required 

5)  read  access  to  a  is  required 

6)  a  =  gcd(A,B) 

7)  (a=b  a  gcd(a,b)=gcd(A,B)  a  a*c+b*d=A*B)  o 
(a=gcd(A,B)  a  c+d=lcm(A,B)) 

8)  (a  =  gcd(A,B)  a  c+d  =  lcm(A,B»  =>  true 

9)  (x  =  a  a  y  =  c  +  d)  ^  (x  =  gcd(A,B)  a  y  =  lcm(A,B)) 

10)  write  access  to  b  is  required 

11)  read  access  to  b  is  required 

12)  a’  and  b’  equal  the  respective  values  of  a  and  b 
prior  to  the  last  execution  of  :1. 1,1.2: 

13)  (((a<a’  v  b<b’)  a  gcd(a,b)=gcd(A,B)  A  a^b)  => 

(a^b  a  gcd(a,b)  =  gcd(A,B))  a  max(a',b’)  >  max(a,b)) 

1  A)  gcd(a,b)  =  gccl(A.B) 

15)  a  ^  b 

16)  gccKa.b)  =  gcd(A.B)  s  gcd(a’,b’)  =  gcd(a,b) 

17)  gccKa.h)  =  gccKa’.b') 

IS)  (a  >  h  a  gccKa’.b’)  =  gcd(a-b,b)  v 
a  <  t>  a  gcd(a’,b')  =  gcd(a,b  a) 

19)  gcd(a’,b’)  =  gcd(a-b,b)  a  A*B  =  (a-b)*c  +  b*(d+c) 

20)  gcd(a’,b’)  =  gcd(a,b-a)  a  A*B  =  at(c+d)  +  (b-a)*d 

21)  <gcd(a’,b’)  =  gcd(a,b-a)  a  A*B  =  (a-b)*c  +  b*(d+c)  )  =>  true, 
b  decreased  by  a  o  gcd(a’,b’)  =  gcd(a,b) 

22)  (gcd(a’,b’)  =  gcd(a-b,b)  a  A*B  =  a*(c+d)  +  (b-a)*d)  ^  true, 
a  decreased  by  b  o  gcd(a,b)  =  gcdfa’.b’) 
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23)  (gcd(a’,b’)  a  a  >  b  a  a*c  +  b*d  =  A*B)  o  gcd(a\b’)  =  gcd(a-b,b)  A 
A*B  -  (a-b)*c  +  b*(d+c)  ) 

24)  (gcd(a’,b’)  a  b  >  a  a  a*c  +  b*d  =  A*B  )  =  gcd(a’,b’)  =  gcd(a,  b-a)  a 
a*c  +  b*d  -  A*B 

25)  write  access  to  y  is  required 

26)  c  and  d  are  integer  variables 

27)  read  access  is  required  for  both  c  and  d 

28)  c  +  d  =  lcm(A,B) 

29)  write  access  is  required  for  c 

30)  write  access  is  required  for  d 

31)  a*c  +  b*d  =  A*B 

32)  A  =  a  a  3  =  b 

Even  though  information  has  been  hidden  from  (k)  (I),  entropy  loadings 
remain  the  same  as  for  the  previous  decompositions  for 

(  g  »  '  )  <  h  ,  j  ), 

but  increase  for  ((c)  ((  g  ,  i  )  (  k  ,  I  ))  ),  i.e. 

((a)  ((b)  ((c)  ((  g  ,  i  )  (  k  ,  I  ))  1.55  )  1.75  )  1.75  )  1.28 

Because  little  information  was  hidden  from  the  ob  ects  at  early  stages, 
entropy  loadings  tended  to  be  larger  than  in  versions  1  and  11. 


*  *  * 

The  three  versions  of  this  gcd  computation  have  indicated  that 
control  mechanisms  usually  share  more  assumptions  in  a  program  than  the 
objects  whose  execution  is  being  controlled.  These  examples  also 
illustrated  several  instances  where  information  was  hidden  from  cbiects. 
In  versions  I  and  II,  this  resulted  in  entropy  loadings  that  were 
smaller  than  corresponding  loadings  had  assumptions  not  been  hidden. 
Version  III,  however,  indicated  that  more  information  was  shared  than  in 
versions  I  and  II.  Entropy  loading  figures  can  be  improved  if  the  texts 
which  compute  the  gcd  are  separated  from  those  which  compute  the  Icm. 
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USING  THE  MEASURE 
A  SEQUENCES  PROBLEM 

A  SEQUENCES  PROBLEM 

This  example  is  also  clue  to  DijKstra[DJ3  pp. 53*63],  but  makes  use 

of  some  of  the  notational  conventions  due  to  Hoare[H03].  The  specific 

conventions  are: 

a)  <empty>  is  a  sequence 

b)  if  x  is  a  sequence  and  d  can  be  an  element  of 
a  sequence  then 

x^"d  is  a  sequence 

c)  The  only  sequences  are  those  defined  by  (a)  and  (b) 

d)  (x'~‘d).last  =  d 

e)  imtial(x~d)  =  x 

f)  x~(y ~z)  =  (x~y)~z 

g)  d.first  =  d 

h)  x  /  <empty>  =>  (x~d).first  =  x. first 

i)  final(d)  =  <empty> 

j)  x  /  <empty>  s  finaKx^d)  =  finalfx^d 

last,  initial,  first,  and  final  are 
not  defined  for  <empty>. 

k)  length(<empty>)  =  0 

l)  length(x~d)  =  succdength(x)) 

m)  x:~d  means  x  <-  x^d 

n)  d  from  x  means  d  «-  x. first;  x  <-  final(x) 

o)  d  back  from  x  means  d  <-  x.last;  x  *-  initial(x) 

p)  from  x  means  x  <-  final(x) 

q)  back  from  x  means  x  «-  initial(x) 

Consider  the  sequences  constructed  from  the  digits  1,  2,  and  3 
which  contain  no  occurrence  of  two  adjacent,  identical  subsequences. 
Call  these  sequences  "good".  Several  examples  of  good  sequences  are 
1 

21 

1312 

31213 

Several  sequences  which  are  not  "good"  are 
22 

123123 

321232123 


The  problem  can  now  be  stated: 
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Assuming  that  there  exists  a  good  sequence  of  length  100,  write  a 
program  which  generates  the  list  of  good  sequences  in  lexicographic 
order  up  to  arid  including  the  first  good  sequence  of  length  100, 
(Here,  1  precedes  2  which  precedes  3). 

A  SEQUENCES  PROBLEM 


:  1 :  (110) 


:1.1:  (112)  (a)  :1.2:  (112) 

(while  length(S) 
/  100  do 
begin 
:1.3:j  :  1 .4: 
end  ) 


:  1 .3:  (113)  :  1 .4:  (113) 


(b)  :  1 . 1 . 1 :  (115) 
S  «-  <empty>; 
length(S)  *-  0) 


('o 


(c)  :  1 .3. 1 :( 1 15)  (d)  :1.4.1:  (116) 
(S  -  next  (PRINT (S);) 
good 

sequence;)  - 


:ll.l.3:( 


(e)  :  1 .3. 1 . 1 :( 1  18)  (f)  :  1 .3. 1  2:(  1  IS)  (g)  :1.3.1.3:(1 19)  (h) 
(  S:^0)  (repeat  (S  next 

:  1 .3. 1 .3 :  larger 

:  1 .3. 1.4:  sequence; 

until  GOODLY 


1.3.1.4:(  1 1 9) 
(set  GOOD  to 
mean  "S  is 
a  good  seq.;) 


(i)  :  1 .3. 1 .3. 1 ;( 1 22 )  (j) 


,1.3.1 .3.2:(  122) 

S  last  ♦-  S.last 


+  1 


(k)  :  1 .3. 1 .3. 1 . 1 :( 1 23) 

(while  S.last  =  3  do 
back  from  S;) 


(I)  :2.1:(  130)  (m)  :2.2:(130) 

length(S)  is  length  S.last  is  d[length] 


(n)  :2.3:(  1 30) 
write  access  to 
S.last  is 
d[length]  «- 


(o)  :2.4:  S  -  S~...  (131)  (p)  :2.5;  (131)  (q)  :2.6:  (131) 

length  «-  length  +  1;  back  from  S  S  *-  <empty> 

d[length]  «-  ...  length  «-  length  -  1  length  «-  0 


(r)  :2.7:  read  access  to  elements  (s)  :2.8:  write  access  to  S 
of  S.  d[l]  ...  d[length]  d[l]  ♦-  ...,  ...  d[length]  «-  ... 

(132)  (132) 


This  problem  requires  that  a  list  of  lexicographically  ordered  sequences 
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of  l’s,  2’s,  and  3’s,  containing  no  adjacent  identical  subsequences,  be 
printed.  This  list  should  terminate  with  the  first  sequence  whose 
length  is  100. 

Object  :1.1:  sets  S  to  <empty>.  Objects  :1.3:  and  -.1.4:  generate  and 
p-int  the  next  good  sequence.  Object  :  1 .2:  controls  objects  :1.3:  and 
:1.4:  until  a  sequence  of  length  100  is  produced. 

Object  :  1.3. 1.1:  extends  S  with  0.  Objects  :  1.3. 1.3:  and  -.1.3. 1.4: 
produce  the  next  lexicographically  larger  sequence  and  test  whether  it 
is  a  good  sequence.  :  1 .3. 1.3:  and  :  1 .3. 1.4:  ar?  controlled  by  :1.3.1.2: 
until  a  good  sequence  is  found. 

Objects  :  1.3. 1.3. 1.1:  and  :1.3. 1.3.2:  remove  trailing  3’s  from  S  and 
increment  the  last  element  of  S  by  1. 

Objects  :2.1 :  through  :2.8:  implement  the  operations  required  by  the 
objects  to  manipulate  a  sequence.  S  is  implemented  in  terms  of  an  array 
and  several  simple  variables. 

:1: 


assumptions:  OS  =  <empty>,  lNlT(R.S)  is  defined  to  be  {if 

length(R)  =  0  then  true  else  R.tirst  =  S.first  a 
INIT(finaKR),  final(S))}  a  a  "good"  sequence  is 
defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 
containing  no  adjacent  idenlical  subsequences  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  there  exists  a  good  sequence  of 
length  100 

:1 :  OUTPL^THE  INITIAL  PORTION  OF  THE  SEQUENCE  OF 
LEXICOGRAPHICALLY  ORDERED  SEQUENCES  OF  l’s,  2’s.AND 
3’s,  SIjCH  THAT  NO  SEQUENCE  CONTAINS  TWO  ADJACENT 
IDENTICAL  SUBSEQUENCES.  TERMINATE  THE  LIST  WITH  THE 
FIRST  SUCH  SEQUENCE  WHOSE  LENGTH  EQUALS  100. 


effects  anb 

post-coT?ditions:  INIT(0S,Q)  a  length(OS.Iast)  =  100 

verification:  If  there  exists  a  "good"  sequence  of  length  100  and 

the  effects  of  :1:  agree  with  the  post-condition, 
the  post -condition  is  satisfied. 
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The  object/assumption  table  for  :1:  is 
i  2  3 

•  l  •  ill 

1)  OS  =  <empty> 

2)  INIT(R.S)  is  defined  to  be  (if  length(R)  =  0  then  true 
olse  R.first  =  S. first  a  lNIT(final(R),final(S))} 

a  a  "good"  sequence  is  defined  to  be  "a  sequence  of  l’s,  2’s,  and 
3’s  containing  no  adjacent  identical  subsequences" 
a  Q  represents  the  sequence  of  lexicographically 
ordered  "good"  sequences 

3)  there  exists  a  good  sequence  of  length  100 
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We  elaborate  :1:  as  follows,  with  all  the  pre-conditions  derived 
:  1 . 1 : 

assumptions:  requires  ability  to  set  S  to  <empty>  and  length(S) 

to  0,  OS  =  <empty>,  INIKR.S)  is  defined  to  be  {if 
length(R)  =  0  then  true  else  R.first  =  S.first  a 

INlT(finaKR),  final(S))}  a  a  "good"  sequence  s 

defined  to  be  "a  sequence  of  l’s,  2  s,  and  3  s 
containing  no  adjacent  identical  subsequences  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  there  exists  a  good  sequence  of 
length  100 

:  1. 1 :  SET  SEQUENCE  S  TO  <empty>  AND  length(S)  TO 
ZERO. 

effects  and 

post-conditions:  S  =  <empty>,  length(S)  =  0,  1NIT(0S,Q), 

length(OS.Iast)  =  100 

(a)  : 1 .2: 

assumptions:  INIKR.S)  is  defined  to  be  {if  length(R)  =  0  then 

true  else  R.first  =  S.first  a 

INIT(final(R),final(S»}  a  a  "good"  sequence  is 
defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 

containing  no  adjacent  identical  subsequences  a  Q 
represents  the  sequence  of  lexicogrdphically  ordered 
"good"  sequences,  there  exists  a  good  sequence  of 
length  100,  INIT(OS.Q)  a  OS.Iast  =  S,  INlT(OS~”next 
lexicographically  larger  good  sequence  than  the 
value  in  S”,Q),  (INIT(OS.Q)  a  OS.Iast  =  S  a 

length^)  H  100)  =>  INIT(0S''"next  lexicographically 

larger  good  sequence  than  the  value  in  S  ,Q) 

requires  ability  to  read  length(S), 

:  1 .2:  while  length(S)  i  100  do 
begin  :  1.3:  ;  :1.A:  end; 

effects  and 

post-conditions:  INIT(0S,Q),  length(OS.Iast)  »  100 

verification:  The  pre-condition  for  the  while  construction  holds 

since  (1)  we  assume  that  there  exists  a  good 

sequence  of  length  equal  to  100;  (2)  OS  =  <empty> 
initially;  (3)  and  that  the  first  good  sequence 

satisfies  the  pre-condition. 
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:  1 .3: 

assumptions: 


effects: 

post-conditions: 

:1.4: 

assumptions: 


effects: 


INIT{R,S)  is  defined  to  be  {if  length(R)  ■  0  then 
true  else  R.first  ■  S.first  a 

lNIT(final(R),final(S)))  a  a  "good"  sequence  is 
defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 
containing  no  adjacent  identical  subsequences"  A  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  requires  ability  to  write  each 
element  of  S,  requires  ability  to  access  each 
element  of  S,  requires  ability  to  concatenate  onto 
S,  i.e.  S  «-  S  d,  requires  ability  to  delete  from 
the  end  of  S,  i.e.  back  from  S,  INIT(OS,Q)  a 
OS.Iast  =  S  a  OS.Iast  =»  S,  lNlT(OS'"next 
lexicographically  larger  good  sequence  than  the 
value  in  S",Q) 

:  1 .3 :  TRANSFORM  S  TO  THE  NEXT  GOOD  SEQUENCE  AFTER 
ITS  CURRENT  CONTENTS 

S  ♦-  "next  good  sequence  after  S" 

INIT(OS~S,Q) 


INIT(R,S)  is  defined  to  be  {if  length(R)  =  0  then 
true  else  R.first  =  S.first  a 

INIT(final(R),final(S))}  a  a  "good"  sequence  is 
defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 
containing  no  adjacent  identical  subsequences"  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  INIT(0S'"'S,Q),  requires  ability  to 
access  each  element  of  S, 

:1.4:  PRINT(S); 

os  ♦-  os~s 


post-conditions: 


INIT(OS.Q)  a  OS.Iast  =  S 
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The  object/assumption  table  for  this  part  is 

I  23456789  10111213 
5  1  i  III 

•  1*  Is  I  I  I  I 

1  I*  2‘  II  till 

;  I  •  3*  I  I  I  I  I  I  I 

:  I  ■  45  I  II 

1)  OS  =  <empty> 

2)  iMIT(R,S)  is  defined  to  be  {if  length(R)  =  0  then  true 
olse  R.first  =  S.first  a  INIT(final(R),final(S))} 

a  a  "good"  sequence  is  defined  to  be  "a  sequence  of  l’s,  2’s,  and 
3’s  containing  no  adjacent  identical  subsequences" 
a  Q  represents  the  sequence  of  lexicog  apiiically 
ordered  "good"  sequences 

3)  there  exists  a  good  sequence  of  length  100 

4)  requires  ability  io  set  S  to  <empty>  and 
length(S)  to  0 

5)  INIT(OS.Q)  a  OS. last  »  S  a  OS.Iast  =  S 

6)  (1NIT(03,Q)  a  OS.Iast  =  S  a  length(S)  *  100)  o 

lNIT(OS'"'"next  lexicographically  larger  good  sequence  than 
the  value  in  S",Q) 

7)  requires  ability  to  read  iength(S) 

8)  lNIT(OS'""next  lexicographically  larger  good  sequence  than 
the  value  in  $",Q) 

9)  1N1T(0S~S,Q) 

10)  requires  ability  to  access  each  element  of  S 

12)  requires  ability  to  concatenate  onto  S,  i.e.  S  ♦*  S^d 

13)  requhes  ability  to  delete  from  the  end  of  S,  i.e.  back  from  S 

We  can  hide  considerable  information  from  the  refinement  for  :  1 . 1 :  by 
adding 

(Assumptions  1),  2),  3)  =>  true)  a  (S  *=  <empty>  a  length(S)  =  0  ? 
Assumptions  1),  2),  3)  ) 

Similarly,  :1.4:(  PRINT(S)  )  does  not  require  1N1T(0S  *S,Q).  Hence  we 
add 

(INlT(OS~S,Q)  ^  true)  a  (OS  =  OS’~S  where  OS’  equals  OS  prior  to  sl.4:  ) 
^  (INIT(OS.Q)  a  OS.Iast  =  S  )  a  OS.Iast  =  S)> 
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Further,  for  :1.3:  (TRANSFORM  S  TO  THE  NEXT  GOOD  SEQUENCE  AFTER  ITS 
CURRENT  CONTENTS.)  we  can  add  the  assumption  below.  (In  the  remainder 
of  this  development,  "illt  is  used  as  an  abbreviation  for  the  phrase  "is 
lexicographically  less  than".) 

(  INIT(OS^"next  good  sequence  after  current  sequence  in  $",Q)  a 
INIT(OS.Q)  a  OS. last  =  S  =  S’  equals  S  prior  to  executing  :1.3:  a  S  is  a 
good  sequence)  a  (Vx[S’  illt  x  illt  S  =  x  is  not  a  good  sequence]  a  S  is 
a  good  sequence  a  S  +  S’  =  tNIT(OS  'S,Q)  ) 

The  elaborat'ons  are 


(b)  :1.1.1: 

assumptions:  requires  ability  to  set  S  to  <empty>  and  length(S) 

to  0 

:1.1.1:  SET  SEQUENCE  S  TO  <empty>  AND  length(S)  TO 
ZERO. 

effects  and 

post-conditions:  S  =  <empty>,  length(S)  *  0 


(c)  : 1 .3. 1 : 

assumptions:  1NIT(R,S)  is  defined  to  be  {if  length(R)  =  0  then 

true  else  R.first  =  S.first  a 

INlT(final(R),final(S»)  a  a  “good"  sequence  is 
defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 

containing  no  adjacent  identical  subsequences"  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  requires  ability  to  access  each 

element  of  S,  requires  ability  to  write  each  element 

of  S,  requires  ability  to  concatenate  onto  S,  i.e. 

S  ♦-  S^ — *d,  requires  ability  to  delete  from  the  end  of 
S,  i.e.  back  from  S,  S’  =  S,  prior  to  executing 

:  1 .3:  a  S  is  a  good  sequence 


:  1.3.1:  TRANSFORM  S  TO  THE  NEXT  GOOD  SEQUENCE  AFTER 
ITS  CURRENT  CONTENTS 


effects:  S  ♦-  "next  good  sequence  after  S" 

post-conditions:  Vx[S’  illt  x  illt  S  ^  x  is  not  a  good  sequence]  a  S 

is  a  good  sequence  a  S  i1  S’  = 
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(d)  :1A1: 

assumptions:  requires  ability  to  access  each  element  of  S 

:1A1:  PRINKS); 

effects:  OS  ♦-  OS^S 


t 


post-conditions: 


(OS  =  OS’~S  where  OS’  equals  OS  prior  to  :1.4s) 
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The  table 


:  |.  |S 

(a)  :  i .  2* 

:  i>  3* 

:  |.  4: 

(b)  :  |.  |.  1: 

(c)  :  1. 3.  1: 

(d)  :  1 .  /).  1 : 


I  23456789  101 1 12131415 161 7 
1111  4 
11  1111 

I  1  I  I  1  I  I  4 


1 


1111  I 

l 


1)  OS  =  <empty> 

2)  IN1T(R,S)  is  defined  to  be  {if  longth(R)  =  0  thon  true 
olse  R.first  =  S.first  a  INlT(f inal(R),final(S))} 

a  a  "good"  sequence  is  defined  to  be  "a  sequence  of  l’s,  2’s,  and 
3’s  containing  no  adjacent  identical  subsequences" 
a  Q  represents  the  sequence  of  lexicographically 
ordered  "good"  sequences 

3)  there  exists  a  good  sequence  of  length  100 

4)  requires  ability  to  set  S  to  <empty>  and 
length(S)  to  0 

5)  INIT(OS.Q)  a  OS. last  =  S 

6)  (INIT(OS.Q)  a  OS.Iast  -  S  a  length(S)  +  100)  o 

INIT(OS'"“"next  lexicographically  larger  good  sequence  than 
the  value  in  S",Q) 

7)  requires  ability  to  read  longth(S) 

8)  INIT(OS'"'"next  lexicographically  larger  good  sequence  than 
the  value  in  S",Q) 

9)  INIT(0S~S,Q) 

10)  requires  ability  to  access  each  element  of  S 

11)  requires  ability  to  write  each  element  of  S 

12)  requires  ability  to  concatenate  onto  S,  i.e.  S  «-  S^d 

13)  requires  ability  to  delete  from  the  end  of  S,  i.e.  back  from  S 

14)  (Assumptions  1),  2),  3)  o  true)  a 

(S  =  <empty>  a  longth(S)  =  0  =  Assumptions  1),  2),  3)  ) 

15)  (INIT(OS''"next  good  sequence  after  current  sequence  in  S”,Q) 
a  INIT(OS.Q)  a  OS.Iast  =  S  = 

S’  equals  S  prior  to  executing  :  1 .3:  a  S  is  a  good  sequence) 
a  (Vx[S’  illt  x  illt  S  ^  x  is  not  a  good  sequence] 
a  S  is  a  good  sequence  a  S  i*  S’  ^ 

INIT(OS~S,Q)  ) 

16)  (INIT(OS'"*S,Q)  =>  true)  a  (OS  =  0S’~S  where  OS’  equals  OS  prior  to 
:  1 .4: 

^  (INIT(OS.Q)  a  OS.Iast  =  S 
a  OS.Iast  =  S)) 

17)  S’  =  S  a  S  is  a  good  sequence 
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After  hiding  information  from  :i.l.l:,  :  1.3. 1 and  :1A1:,  the  best 

decomposition  is 

((b)  (  a  ,  c  ,  d  ))  .562 

where  (b)  sets  S  to  <empty>  and  z,  c,  d  compute  good  sequences  and 
print,  respectively. 

Next  we  elaborate  -.1.3.1:  to 

(e)  :  1 .3. 1. 1 : 

assumptions:  1NIT(R,S)  is  defined  to  be  (if  length(R)  =  0  then 

true  else  R. first  =  S. first  A 

INIT(final(R),fmal(S))}  a  a  "good"  sequence  is 
defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 
containing  no  adjacent  identical  subsequences"  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  requires  ability  to  cor, catenate 
onto  S,  i.e.  S  «-  S~d,  S’  =  S  a  S  is  a  good  sequence 

:  1.3. 1.1:  EXTEND  S  WITH  ZERO; 

effects:  S  =  S’~0 

post-conditions:  imtial(S)  is  a  good  sequence  a  S.last  =  0 

(f)  :  1 .3. 1.2: 

assumptions:  1NIT(R,S)  is  defined  to  be  (if  length(R)  =  0  then 

true  else  R.first  =  S. first  a 

INlT(final(R),final(S»}  a  a  "good"  sequence  is 
defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 
containing  no  adjacent  identical  subsequences'  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  requires  read  access  to  the 
boolean  variable  GOOD,  S"  =  S,  3x[S"  illt  x  a 
length(x)  <  length(S")  a  x  is  a  good  sequence]  a 
((initial(S)  is  good)  a  S.last  =  0  ^  S  is  not  good] 


post-conditions: 


:  1 .3. 1 .2:  repeat  :  1.3. 1.3:  ;  :1.3.1.fl:  ;  until  GOOD; 

GOOD  a  there  is  no  sequence  s  such  that  S”  illt  s 
illt  S  a  s  is  a  good  sequence 
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(g)  :  1.3. 1.3: 

assumptions:  INlTlR.S)  is  defined  to  be  {if  length(R)  =  0  then 

true  else  R.first  =  S.first  a 

lNIT(final(R),final(S))}  a  a  "good"  sequence  is 

defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 

containing  no  adjacent  identical  subsequences"  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  requires  ability  to  access  each 
element  of  S,  requires  ability  to  write  each  element 

of  S,  requires  ability  to  concatenate  onto  S,  i.e. 

S  «-  S^d,  requires  ability  to  delete  from  the  end  of 
S,  i.e.  back  from  S,  S"  =  S,  3x[$"  illt  x  length(x) 

<  longthfS")] 

:  1.3. 1.3:  SET  S  TO  BE  THE  NEXT  LEXICOGRAPHICALLY 
LARGER  SEQUENCE  AFTER  THE  CONTENTS  OF  S  AT  THE  START 
OF  :1.3.1 .3:,  (I.E.  S"),  SUCH  THAT  length(S)  < 

length(S"). 

effects  and 

post-conditions:  S"  illt  S,  length(S)  <  length(S"),  ->3x[S"  illt  x 

illt  S],  imtial(S)  is  good,  S.last  (  {1,2,3} 

(h)  :1.3.1.4: 

assumptions:  INiT(R,S)  is  defined  to  be  {if  iength(R)  ■=  0  then 

true  olso  R.first  =  S.first  A 

lNlT(final(R),final(S))}  A  a  "good"  sequence  is 
defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 
conlaining  no  adjacent  identical  subsequences"  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  requires  ability  to  access  each 
element  of  S,  inilial(S)  is  a  good  sequence, 

requires  write  access  to  the  boolean  variable  GOOD 

:  1.3. 1.4:  SET  THE  VARIABLE,  GOOD,  TO  MEAN  "S  is  a 
good  sequence" 

effects:  GOOD  =  if  "S  is  a  good  sequence"  then  true  else 

false 

GOOD  =  if  "$  is  a  good  sequence"  then  true  else 
false,  S  H  S’ 


post-conditions: 
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verification:  Note  first  that  the  following  are  theorems: 

(a)  If  initiaKS)  is  a  good  sequence,  but  S  is  not  a 
good  sequence,  then  no  extension  of  S  will  be  good. 

(b)  The  only  time  S  should  be  extended,  in  an  effort 
to  find  lexicographically  larger  good  sequences  is 
when  S  itself  is  a  good  sequence. 

Now,  the  only  place  in  the  above  program  where  S  is 
extended  is  at  :  1 .3. 1 :,  where  S  is  guaranteed  to  be 
good.  :1.3.3:  guarantees  that  no  relevant  sequence 
is  missed. 

The  object/assumption  table  now  becomes: 

123456789  1011 12 1314 151 61 71 8192021222324 
(•)  •  I  •  3-  I  •  I  •  I  I  I 

(0  •  I  •  3-  I  •  2*  I  III 

(g)  •  !•  3-  I-  3!  I  I  I  I  I  II 

(h)  :  |.  3.  |.  4:  1  1  ,  1 

1)  OS  =  <empty> 

2)  INIT(R,S)  is  defined  to  be  {if  length(R)  =  0  then  true 
olse  R.first  =  S. first  a  INIT(final<R),final(S))} 

a  a  "good"  sequence  is  defined  to  be  "a  sequence  of  l’s,  2’s,  and 
3’s  containing  no  adjacent  identical  subsequences" 
a  Q  represents  the  sequence  of  lexicographically 
ordered  "good"  sequences 

3)  there  exists  a  good  sequence  of  length  100 

4)  requires  ability  to  set  S  to  <empty>  and 
length(S)  to  0 

5)  INIT(0S,Q)  a  OS.Iast  -  S 

6)  (INIT(OS,Q)  a  OS.Iast  -  S  a  length(S)  +  100)  = 

INlT(OS^"next  lexicographically  larger  good  sequence  than 
the  value  in  S",Q) 

7)  requires  ability  to  read  longth(S) 

8)  INIT(OS^"next  lexicographically  larg<  r  good  sequence  than 
the  value  in  S",Q) 

9)  INIT (OS  “S,Q> 

10)  requires  ability  to  access  each  element  of  S 

11)  requires  ability  to  write  each  element  of  S 

12)  requires  ability  to  concatenate  onto  S,  i.e.  S  *-  S^d 

13)  requires  ability  to  delete  from  the  end  of  S,  i.e.  back  from  S 

14)  (Assumptions  1),  2),  3)  =  true)  a 

(S  =  <empty>  a  lengtWS)  =  0  =  Assumptions  1),  2),  3)  ) 

15)  INIT(OS~"next  good  sequence  after  current  sequence  in  S“,Q) 
a  INIT(OS.Q)  a  OS.Iast  »S  = 

S’  equals  S  prior  to  executing  :  1 .3:  A  S  is  a  good  sequence 
a  Vx[S’  illt  x  illt  S  3  x  is  not  a  good  sequence] 
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a  S  is  a  good  sequence  a  S  +  S’ 

INIT(OS~S,Q) 

16)  (INIT(OS~S,Q)  =  true)  a 

(OS  =  OS’^S  where  OS’  equals  OS  prior  to  :  1 .4: 

3  (INIT(OS.Q)  a  OS.Iast  =  S 
a  OS.Iast  *■  S)) 

17)  S’  ■  S  a  S  is  a  good  sequence 

18)  imtiaKS)  is  a  good  sequence 

19) 

20)  requires  read  access  to  the  boolean  variable  GOOD 

21)  requires  write  access  to  the  boolean  variable  GOOD 

22)  3x[S"  illt  x  a  length(x)  <  length(S”)  a 

x  is  a  good  sequence]  a  [(imtial(S)  is  good)  a  S.last  =  0 
=>  S  is  not  good] 

23)  S"  =  S 

24)  3x[S"  illt  x  length(x)  <  length(S”)] 

The  expansion  of  (c)  -  :  1 .3. 1 .3:  -  implies 

RLB:  ((b)  (  a  ,  c  ,  d  ))  .053 
RUB:  ((b)  (  a  ,  c  ,  d  ))  .410 
with  the  actual  entropy  loadings 

((b)  (  a  ,  o  ,  f  ,  g  ,  h  ,  d  ))  .410 
The  best  decomposition  of  this  elaboration  is 

((b)  ((d)  ((a)  ((e)  ((f)  (  g  ,  h  ))  1.28  )  1.28  )  .956  )  .683  )  .410 
Here,(b)  sets  S  to  <empty>,(d)  prints  S,  (a)  is  the  outer  loop  while 
construction  and  (e)  extends  S  with  a  zero.  In  this  example,  the 

objects  which  calculate  the  next  lexicographically  larger  sequence  and 
which  decide  whether  S  is  a  good  sequence  interact  most. 
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Consider  next  an  expansion  of  :1.3. 1.3: 


(i):  1.3. 1.3.1: 

assumptions:  1N1T(R,S)  is  defined  to  be  {if  length(R)  =  0  then 

true  else  R.first  =  S.first  a 

lN!T(final(R),f  inal(S))}  a  a  “good"  sequence  is 
defined  to  be  "a  sequence  of  i’s,  2’s,  and  3’s 
containing  no  adjacent  identical  subsequences"  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  S"  =  S,  initial(S)  is  a  good 

sequence  a  0  <  S.last  <  3,  ability  to  read  S.last, 
requires  ability  to  delete  from  the  end  of  S,  i.e. 
back  from  S 

:  1.3. 1.3.1:  REMOVE  TRAILING  3’s  FROM  S 


effects  and 

post-conditions:  INIT(S,S"),  initial(S)  is  a  good  sequence  A  0  < 

S.last  <  3 

( j ):  1 .3. 1.3.2: 

assumptions:  1N1T(R,S)  is  defined  to  be  {if  length(R)  =  0  then 

true  else  R.first  =  S.first  A 

INIT(final(R),final($))}  A  a  "good"  sequence  is 

defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 

containing  no  adjacent  identical  subsequences"  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  ability  to  read  S.last,  ability  to 

write  S.last 


:  1.3. 1  3.2:  S.last  S.last  +  1 


effects  and 
post-conditions: 


S"  illtS,  length(S)  <  length(S"),  ^[S"  illt  x  lilt 
S],  mitial(S)  is  good,  S.last  (  {1,2,3} 


The  expansion  of  :  1 .3. 1 .3:  suggests 

RLB:  ((b)  ((d)  ((a)  ((e)  (  f  ,  g  ,  h  )  .562  )  .801  )  .563  )  .138 
RUB:  ((b)  ((d)  ((a)  ((e)  (  f  ,  g  ,  h  )  1.32  )  .900  )  .693  )  .377 
and  the  actual  entropy  loadings  are 

((b)  ((d)  ((a)  ((e)  ((h)  «f)<  i  ,  j  ) 
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1.21  )  .662  )  .727  )  .900  )  .562  )  .377 


Since  the  assumptions  made  by  an  object  imply  any  subset  of  those 
assumptions,  we  can  add  an  additional  assumption  to  :  1 .3. 1 3. 1  :(t  he 
object  which  removes  trailing  three’s)  and  hide  "imtiaKS")  is  good  and 

0  <  S.last  <  3"  from  its  expansion  :  1 .3. 1 .3. 1.1: 

(10:1.3.1.3  1.1: 

assumptions:  1N1T(R,S)  is  defined  to  be  {if  length(R)  =  0  then 

true  else  R.first  =  S.first  a 

INIT(final(R),f  inal(S))}  a  a  “good"  sequence  is 
defined  to  be  "a  sequence  of  l’s,  2’s,  and  3’s 

containing  no  adjacent  identical  subsequences"  a  Q 
represents  the  sequence  of  lexicographically  ordered 
"good"  sequences,  S"  =  S,  ability  to  read  S.last, 

requires  ability  to  delete  from  the  end  of  S,  i.e. 
back  from  S 

:  1.3. 1.3. 1.1:  while  S.last  =  3  do 
back  from  S; 

effects  and 

post-conditions:  1NIT(S,S")  A  S.last  +  3 

The  entropy  loadings  of  the  previous  decomposition  are  identical  for  the 
refinement  including  the  elaboration  for  :  1 .3. 1 .3. 1.1:. 

:1.3.1.4:(decide  whether  S  is  a  good  sequence)  can  be  expanded  by  hiding 
most  of  the  assumptions  of  :  1.3.1. A:.  However,  the  assumption 

"imtial(S)  is  a  good  sequence"  simplifies  the  calculations  since  only 

adjacent  sequences,  one  of  which  contains  S.last,  need  be  considered. 


USING  THE  MEASURE 
A  SEQUENCES  PROBLEM 


The  table  for  the  program  is  now 

I  23456789  1011 12 13 14 15 16 17 1 819202 122232425262728 


‘  l: 

:  |.  i: 

1  1 

III  * 

(a) 

•  !•  2* 

II  1  1  l  1 

*•1-35 

1  l  l  1  1  1  1  4 

S  4‘. 

1  II  * 

(b) 

:  I.  |. 

1 

(c) 

:  1-3-  !'• 

1  1  1  1  1  1 

(d) 

:  |.  4.  |*. 

1 

(e) 

!  I-  3-  I-  Is 

1  1  t 

(f) 

*•  1  ■  3'  1  •  2- 

l 

(g) 

s  1 •  3-  1  •  3* 

1  1  1  1  1 

(h) 

:  1.3.  |.  e\: 

1  1 

(i) 

*  t  •  3-  1-3'  Is 

l  1 

(i) 

‘  1-3-  !•  3-  2* 

1 

(k) 

!  I-  3-  h  3-  I-  \‘ 

1  1 

1) 

OS  =  <empty> 

2) 

INIT(R,S)  is  defined 

to  be  {if  longth(R)  =  0  then  true 

else  R.first  =  S.first  A  INIT(f;,nal(R),final(S))} 

a  a  "good"  sequence  is  defined  to  be  "a  sequence  of  l’s,  2’s,  and 
3’s  containing  no  adjacent  identical  subsequences" 
a  Q  represents  the  sequence  of  lexicographically 
ordered  "good"  sequences 

3)  there  exists  a  good  sequence  of  length  100 

4)  requires  ability  to  set  S  to  <empty>  and 
length(S)  to  0 

5)  INIT(OS,Q)  a  OS. last  =  S 

6)  (INIT(OS.Q)  a  OS  last  =  S  a  length(S)  t  100)  :> 

INIT(OS~"next  lexicographically  larger  good  sequence  than 
the  value  in  S",Q) 

7)  requires  ability  to  read  length(S) 

8)  INIT(OS~"next  lexicographically  larger  good  sequence  than 
the  value  in  S",Q) 

9)  lNIT(OS~S,Q) 

10)  requires  ability  to  access  each  element  of  S 

11)  requires  ability  to  write  each  element  of  S 

12)  requires  ability  to  concatenate  onto  S,  i.e.  S  «-  S^d 

13)  requires  ability  to  delete  from  the  end  of  S,  i.e.  back  from  S 

14)  (Assumptions  1),  2),  3)  ^  true)  a 

(S  =  <empty>  a  length(S)  =  03  Assumptions  1),  2),  3)  ) 

15)  INIT(OS~"next  good  sequence  after  current  sequence  in  S",Q) 
a  INIT(OS.Q)  a  OS. last  =  $3 

S’  equals  S  prior  to  executing  :1.3:  a  S  is  a  good  sequence 
a  Vx[S’  illt  x  illt  S  3  x  is  not  a  good  sequence] 
a  S  is  a  good  sequence  a  S  i1  S’  3 
INIT(OS~$,Q^ 

16)  (INIT(0S~S,Q)  ^  true)  a 
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(OS  =  OS’~S  where  OS’  equals  OS  prior  to  :1.4: 

^  (INIT(OS.Q)  a  OS. last  »  S 
A  OS. last  =  S)) 

17)  S’  =  S  a  S  is  a  good  sequence 

18)  mitial(S)  is  a  good  sequence 

19) 

20)  requires  read  access  to  the  boolean  variable  GOOD 

21)  requires  write  access  to  the  boolean  variable  GOOD 

22)  3x[S"  illt  x  a  length(x)  <  length(S")  a 

x  is  a  good  sequence]  a  [(initial(S)  is  good)  A  S.last  =  0 
^  S  is  not  good] 

23)  S"  =  S 

24)  3x[$"  illt  x  length(x)  <  longth(S")] 

25)  initial(S)  is  a  good  sequence  a 
0  <  S.last  <  3 

26)  (Assumptions  2,  13,23,25,  27)  o 

(Assumptions  2,  13,  23,  27) 

27)  ability  to  read  S.last 

28)  ability  to  write  S.last 
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At  about  this  stage  in  the  development,  DijKstra  introduces  a  data 
structure,  namely  an  array  d[l:100]  to  hold  the  digits  of  S.  The 
variable,  length,  is  introduced  such  that  S.last  ■  d[length].  By  making 
this  decision,  all  references  to  operations  involving  S  or  the  operator 
length  require  additional  assumptions.  These  assumptions  are  as 
follows: 


"ability  to  access  length(S)"  becomes 

length 

d  is  an  array  which  contains  the  digits  of  S,  one  digit  per  element  a 
the  variable  length  indexes  the  last  element  of  S  a  the  sequence  is 
empty  when  length  =  0,  ability  to  read  the  variable  length 

"ability  to  read  S.last"  becomes 

d[length] 


and  assumes 

d  is  an  array  which  contains  the  digits  of  S,  one  digit  per  element  a 
the  variable  length  indexes  the  last  element  of  S  a  the  sequence  is 

empty  when  length  ■  0,  ability  to  read  the  variable  length,  ability  to 

read  d[length] 

"ability  to  write  S.last"  becomes 

d[length]  «-  ... 

d  is  an  array  which  contains  the  digits  of  S,  one  digit  per  element  a 
the  variable  length  indexes  the  last  element  of  S  a  the  sequence  is 

empty  when  length  -  0,  ability  to  read  the  variable  length,  ability  to 

write  d[length] 

"ability  to  concatenate  onto  S"  becomes 

length  «-  length  +  1;  d[length]  <-  ... 


and  assumes 

d  is  an  array  which  contains  the  digits  of  S,  one  digit  per  element  a 
the  variable  length  indexes  the  last  element  of  S  a  the  sequence  is 
empty  when  length  =  0,  ability  to  read  the  variable  length,  ability  to 
write  the  variable  length,  ability  to  write  d[length] 
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"ability  to  delete  from  the  end  of  S,  i.e.  back  from  S"  becomes 

length  «-  length  -  1; 


and  assumes 

d  is  an  array  which  contains  the  digits  of  S,  one  digit  per  element  a 
the  variable  length  indexes  the  last  element  of  S  a  the  sequence  is 

empty  when  length  -  0,  ability  to  read  the  variable  length,  ability  to 

write  the  variable  length 

"ability  to  set  S  to  <empty>"  becomes 

length  «-  0; 


and  assumes 

d  is  an  array  which  contains  the  digits  of  S,  one  digit  per  element  A 

the  variable  length  indexes  the  last  element  of  S  a  the  sequence  is 

empty  when  length  ■=  0,  ability  to  write  the  variable  length, 

"ability  to  read  every  element  of  S"  requires 

d  is  an  array  which  contains  the  digits  of  S,  one  digit  per  element  a 

the  variable  length  indexes  the  last  element  of  S  a  the  sequence  is 

empty  when  length  =  0,  ability  to  read  the  variable  length,  ability  to 

read  every  element  of  d 

"ability  to  write  every  element  of  S"  requires 

d  is  an  array  which  contains  the  digits  of  S,  one  digit  per  element  a 

the  variable  length  indexes  the  last  element  of  S  a  the  sequence  is 

empty  when  length  =  0,  ability  to  read  the  variable  length,  ability  to 

write  the  variable  length,  ability  to  write  every  element  of  d 

The  object/assumption  table  for  this  introduction  is 
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I  23456789  101 1 12I3I4I5I61 7 1 81 9202 1 2223242526272829303 132333435 
*  I*  ill 


s  |.  |! 

1  1  1  1  • 

1 

1 

:  |.  2* 

It  1  1  1  1 

1 

1 

!  !•  3s 

1  1  1  l  1  1  l  ♦ 

1 

1 

1 

1 

1  l 

*1-4* 

1  II  ♦ 

1 

1 

1 

: |.  |.  |t 

1 

1 

S  1-  3-  IS 

1  1  1  1  1  1 

1 

1 

1 

1 

1  1 

*1-4-  I* 

1 

1 

1 

1 

*1-3-  I-  I* 

1  l  1 

1 

1 

1 

1 

•  1*  3-  !•  2* 

1  1 

1  1 

S  !•  3-  !•  3* 

1  1  1  1  1 

1  1  1 

1 

1 

1 

1  1 

s  1.3.  |.4: 

1  1  1 

1 

1 

1 

*1-3-  1-3-  i: 

1  1 

1  1  1  1 

1 

1 

1 

8  13*  13-  2* 

1 

1  1  1 

1 

1  l 

*1-3-  1-3-  I-  I8 

1  1 

1  I  1 

1 

1 

1)  OS  =  <empty> 

2)  1NIT(R,S)  is  defined  to  be  {if  lengtWR)  =  0  then  true 

else  R.first  =  S.first  a  INIT(final(R),final(S))} 

a  a  "good"  sequence  is  defined  to  be  "a  sequence  of  l’s,  2’s,  and 
3’s  containing  no  adjacent  identical  subsequences" 
a  Q  represents  the  sequence  of  lexicographically 
ordered  "good"  sequences 

3)  there  exists  a  good  sequence  of  length  100 

4)  requires  ability  to  set  S  to  <empty>  and 
length(S)  to  0 

5)  IN1T(0S,Q)  a  OS.Iast  =  S 

6)  (INIT(OS.Q)  a  OS.Iast  =  S  a  length(S)  *  100)  a 

INIT(OS''"next  lexicographically  larger  good  sequence  than 
the  value  in  S",Q) 

7)  requires  ability  to  read  length(S) 

8)  INIT(OS~*"next  lexicographically  larger  good  sequence  than 
the  value  in  S",Q) 

9)  INITfOS-'S.Q) 

10)  requires  ability  to  access  each  element  of  S 

11)  requires  ability  to  write  each  element  of  S 

12)  requires  ability  to  concatenate  onto  S,  i.e.  S  *-  S*^d 

13)  requires  ability  to  delete  from  the  end  of  S,  i.e.  back  from  S 

14)  (Assumptions  1),  2),  3)  a  true)  a 

(S  =  <empty>  a  length(S)  *03  Assumptions  1),  2),  3)  ) 

15)  INIKOS^next  good  sequence  after  current  sequence  in  S",Q) 
a  INIT(OS.Q)  a  OS.Iast  =  $3 

S’  equals  S  prior  to  executing  :1.3:  a  S  is  a  good  sequence 
a  Vx[$’  ilit  x  illt  S  3  x  is  not  a  good  sequence] 
a  S  is  a  good  sequence  a  S  f  S’  3 
INIT(OS~S,Q) 

16)  (INIT(OS~S,Q)  a  true)  a 

(OS  =  OS’^S  where  OS’  equals  OS  prior  to  :1.4; 
a  (INIT(OS.Q)  a  OS.Iast  =  S 
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a  OS. Iasi  -  S)) 

17)  S’  •  S  a  S  is  a  good  sequence 

18)  initial(S)  is  a  good  sequence 

19) 

20)  requires  read  access  to  the  boolean  variable  GOOD 

21)  requires  write  access  to  the  boolean  variable  GOOD 

22)  3x[S"  illt  x  A  length(x)  <  length(S")  a 

x  is  a  good  sequence]  A  [(initial(S)  is  good)  A  S.last  *  0 
^  S  is  not  good] 

23)  SM  =  S 

24)  3x[S"  illt  x  length(x)  <  lengths' )] 

25)  initial(S)  is  a  good  sequence  a 
0  <  S.last  <  3 

26)  (Assumptions  2,  13,23,25,  27)  ? 

(Assumptions  2,  13,  23,  27) 

27)  ability  to  read  S.last 

28)  ability  to  write  S.last 

29)  d  is  an  array  which  contains  the  digits  of  S, 
one  digit  per  element  A  the  variable  length 
indexes  the  last  element  of  S  A  the  sequence  is 
empty  when  length  =  0 

30)  ability  to  read  the  variable  length 

31)  ability  to  write  the  variable  length 

32)  ability  to  write  d[length] 

33)  ability  to  read  d[length] 

34)  ability  to  read  every  element  of  d 

35)  ability  to  write  every  element  of  d 

It  will  be  noted  that  the  shared  information  between  the  parts  has 

increased  significantly  by  the  decision  to  distribute  all  the 

information  about  the  implementation  of  the  sequence.  In  particular, 
the  entropy  'loadings  for  the  last  decomposition  are 
((b)  ((d)  ((a)  ((e)  ((h)  ((f)  (  k  ,  j  )) 

1.21  )  1.21  )  1.91  )  1.38  )  1.21  )  1.21 

All  these  values  are  greater  than  or  equal  to  the  corresponding  values 
from  the  same  decomposition  of  the  previous  table. 


As  an  alternative  to  distributing  additional  assumptions  throughout 
the  program,  objects  can  be  created  which  provde  the  effects  which  are 


needed. 
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(I)  :2.1: 
assumptions: 


effects: 

post-conditions: 
(m)  :2.2: 
assumptions: 


effects: 

post-conditions: 
(n)  :2.3: 
assumptions: 


offsets: 


d  is  an  array  which  contains  the  digits  of  S,  one 
digit  per  element  a  the  variable  length  indexes  the 
last  element  of  S  a  the  sequence  is  empty  when 
length  =  0,  ability  to  read  the  variable  length 

:2.1:  PROVIDE  THE  ABILITY  TO  ACCESS  THE  LENGTH  OF  S, 
I.E.  ACCESS  THE  VALUE  OF  length 


length(S)  -  length 

length(S)  equals  the  length  of  S  according  to  the 
definition  of  length 


d  is  an  array  which  contains  the  digits  of  S,  one 
digit  per  element  a  the  variable  length  indexes  the 
last  element  of  S  a  the  sequence  is  empty  when 
length  =  0,  ability  to  read  the  variable  length, 

ability  to  read  d[length] 

:2.2:  PROVIDE  THE  ABILITY  TO  READ  S.last,  I.E.  SET 
THE  VALUE  OF  S.last  TO  d[length] 

S.last  *>  d[length] 

S.last  equals  the  value  of  the  last  element  of  S 
according  to  the  definition  of  S.last 


d  is  an  array  which  contains  the  digits  of  S,  one 
digit  per  element  a  the  variable  length  indexes  the 
last  element  of  S  a  the  sequence  is  empty  when 
length  =  0,  ability  to  read  the  variable  length, 
ability  to  write  d[length] 

:2.3:  PROVIDE  THE  ABILITY  TO  WRITE  S.last  I.E. 
d[length]  <-  ... 

S.last  can  be  used  as  a  name  to  cause  a  value  to  be 
stored  into  d[length] 


post-conditions: 


A  value  has  been  assigned  to  A.last 
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(o)  :2 .4: 

assumptions:  d  is  an  array  which  contains  the  digits  of  S,  one 

digit  per  element  a  the  variable  length  indexes  the 
last  element  of  S  a  the  sequence  is  empty  when 
length  =  0,  ability  to  read  the  variable  length, 

ability  to  write  the  variable  length,  ability  to 

write  d[length] 

■2A:  PROVIDE  THE  ABILITY  TO  CONCATENATE  ONTO  S, 
I.E.  length  «-  length  +  1;  d[length]  «-  ... 

effects  and 

post-conditions:  The  definition  for  concatenation  is  satisfied 

(p)  :2.5: 

assumptions:  d  is  an  array  which  contains  the  digits  of  S,  one 

digit  per  element  A  the  variable  length  indexes  the 

last  element  of  S  a  the  sequence  is  empty  when 

length  =  0,  ability  to  read  the  variable  length, 

ability  to  write  the  variable  length 

:2.5:  PROVIDE  THE  ABILITY  TO  DELETE  THE  END  OF  S, 
I.E.  back  from  S,  I.E.  length  «-  length  -1; 

effects  and 

post-conditions:  the  definition  for  back  from  S  is  satisfied. 

(q)  :2.6: 

assumptions:  d  is  an  array  which  contains  the  digits  of  $,  one 

digit  per  element  a  the  variable  length  indexes  the 

last  element  of  S  a  the  sequence  is  empty  when 

length  =  0,  ability  to  write  the  variable  length 

:2.6:  PROVIDE  THE  ABILITY  TO  SET  S  TO  <empty>  I.E. 
length  «-  0 

effects:  length  =  0 


post-conditions: 


S  ■  <empty> 
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(r)  :2.7: 

assumptions:  d  is  an  array  which  contains  the  digits  of  S,  one 

digit  per  element  a  the  variable  length  indexes  the 

last  element  of  S  a  the  sequence  is  empty  when 

length  =  0,  ability  to  read  the  variable  length, 

ability  to  read  every  element  of  d 

:2.7:  PROVIDE  THE  ABILITY  TO  READ  EVERY  ELEMENT  OF  S 
It.  READ  ACCESS  to  d[l]  ...  d[length] 

effects  and 

post-conditions:  every  element  of  S  is  readable 

(s)  :2.8: 

assumptions:  d  is  an  array  which  contains  the  digits  of  S,  one 

digit  per  element  a  the  variable  length  indexes  the 

last  element  of  S  a  the  sequence  is  empty  when 

length  «=  0,  ability  to  read  the  variable  length, 

ability  to  write  every  element  of  d 

:2.8:  PROVIDE  ABILITY  TO  WRITE  EVERY  ELEMENT  OF  S 
d[l]  «-  . d[length]  «-  ... 

•(facts  and 

post-conditions:  every  element  of  S  has  been  made  writable. 
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The 

table 

for  the  program  with  these  additional  parts  is 

12  3  4  5 

6  7  8  9  I0III2I3I4I516I7I81 9202 1 2223242526272829303 1 32333435 

•  1  • 

:  i .  i : 
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♦ 
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1  1  1 

1  1  1 

:  |.  3: 

1  1 

1  1  1  1  1  * 

:  i .  xj: 

1 

1  !  * 

(b) 

:  I.  |. 

\‘  1 

:  |.  3- 

1*  1 

1  1  1  1  1 

(d) 

S  |.  4. 

1  • 

1 

(e) 

*•  1  •  3- 

I-  |S  1 

1  1 

, 

(f) 

:  l  •  3 

1  •  2-  1 

1  1  1 

•*  1  •  3- 

!•  3*  1 

till  II 

(h) 

1  I-  3- 

1-45  ! 

1  1  1 

(i) 

:  |.  3- 

1  •  3*  I*  1 

1  III 

(j) 

:  |.  3- 

1-3-22  1 

1 

1 

(k) 

s  t .  3- 

1  •  3-  1  •  1  *•  1 

1  1  1 

(1) 

J  2-  1 

1  l 

(m) 

i 2 •  2 

1  1  1 

(n) 

•  2-  3 

l  l  1 

(o) 

s  2- 

1  l  1  1 

(P) 

’ 2 ■  5 

1  1  1 

(q) 

1  2-  6 

1  1 

(r) 

•2-  7 

1  1  1 

(s) 

s 2 •  8 

1  1  1 

1) 

OS  = 

<empty> 

2) 

INIT(R.S)  is  defined  to 

be  (if  length(R)  =  0  then  true 

olse 

R.first  =  S. first  A 

lNlT(final(R),final(S))} 

A  a 

"good"  sequence 

s  defined  to  be  "a  sequence  of  l’s,  2’s,  and 

3’s  containing  no  adjacent  identical  subsequences" 
a  Q  represents  the  sequence  of  lexicographically 
ordered  "good"  sequences 

3)  there  exists  a  good  sequence  of  length  100 

4)  requires  ability  to  set  S  to  <empty>  and 
length(S)  to  0 

5)  1N1T(0S,Q)  a  OS. last  ■=  S 

6)  (1N1T(0S,Q)  a  OS. last  =  S  a  longth(S)  /  100)  s 

INIT(OS'"'"next  lexicographically  larger  good  sequence  than 
the  value  in  S",Q) 

7)  requires  ability  to  read  length(S) 

8)  INlT(OS"'"next  lexicographically  larger  good  sequence  than 
the  value  in  S",Q) 

9)  INIT<OS~S,Q) 

10)  requires  ability  to  access  each  element  of  S 

11)  requires  ability  to  write  each  element  of  S 

12)  requires  ability  to  concatenate  onto  S,  i.e.  S  «-  S~d 

13)  requires  ability  to  delete  from  the  end  of  S,  i.e.  back  from  S 
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14)  (Assumptions  1),  2),  3)  =>  true)  A 

(S  =  <empty>  A  length(S)  =  0  ^  Assumptions  1),  2),  3)  ) 

15)  INIT(OS~"next  good  sequence  after  current  sequence  in  S",Q) 
a  INIT(OS.Q)  a  OS.Iast  =  S  => 

S’  equals  S  prior  to  executing  :1.3:  A  S  is  a  good  sequence 
a  Vx[S’  lilt  x  illt  S  ^  x  is  not  a  good  sequence] 

A  S  is  a  good  sequence  a  S  /  S’  ^ 

1N1T(0S~S,Q) 

16)  (IN1T(0S~S,Q)  ^  true)  a 

(Ob  =  OS'^S  where  OS’  equals  OS  prior  to  :  1 .4: 

^  (INIKOS.Q)  a  OS.Iast  =  S 
A  OS.Iast  =  S)) 

17)  S’  =  S  a  S  is  a  good  sequence 

18)  initial(S)  is  a  good  sequence 

19) 

20)  requires  read  access  to  the  boolean  variable  GOOD 

21)  requires  write  access  to  the  boolean  variable  GOOD 

22)  3x[S"  illt  x  a  length(x)  <  lengtMS")  a 

x  is  a  good  sequence]  A  [(initial(S)  is  good)  a  S.last  =  0 
o  S  is  not  good] 

23)  S"  =  S 

24)  3x[S"  illt  x  length(x)  <  length(S")J 

25)  initial(S)  is  a  good  sequence  a 
0  <  S.last  <  3 

26)  (Assumptions  2,  13,23,25,  27)  o 

(Assumptions  2,  13,  23,  27) 

27)  ability  to  read  S.last 

28)  ability  to  wnte  S.last 

29)  d  is  an  array  which  contains  the  digits  of  S, 
one  digit  per  element  a  the  variable  length 
indexes  the  last  element  of  S  a  the  sequence  is 
empty  wl  en  length  =  0 

30)  ability  to  read  the  variable  length 

31)  ability  to  write  the  variable  length 

32)  ability  to  write  d[length] 

33)  ability  to  read  d[length] 

34)  ability  to  read  every  element  of  d 

35)  ability  to  write  every  element  of  d 

An  examination  of  this  table  leads  to  the  following  decomposition.  It 
shows  better  entropy  loading  values  than  for  the  table  where  the 
implementation  information  is  distributed 
((b)  <(*)  ((d)  ((a)  ((e)  ((h)  ((f)  (  k  ,  j  )) 


.987  )  .711  )  .744  )  .831  )  .377  )  .497  )  .234 
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*:  (0)  ((r)  Us)  ((m)  Uq)  «n)  (  o  ,  p  )) 

1.1.  )  1.02)  .920  )  .942  )  .974  )  .881 

This  example  indicates  that  complicated  interpretations  of  the  contents 
of  variables  can  lead  to  high  entropy  loadings  if  that  information  is 
distributed.  The  structure  can  be  improved  if  additional  objects  are 
introduced  which  provide  the  effects  of  these  complicated  assumptions. 


USING  THE  MEASURE 
HEAPSORT 


HEAPSORT 


The  sorting  algorithm  HEAPSORT  has  been  described[WIL], 

explained[KN2],  and  verified(via  the  text  of  TREE$0RT3[L0]).  However, 

these  descriptions  and  proofs  remain  difficult  to  follow,  not  because 

the  algorithm  is  difficult,  but  because  a  reader  must  understand 

operators  which  manipulate  a  tree  structure  in  terms  of  an 

implementation  of  that  tree  structure  as  an  array.  In  this  example, 

TREESORT3  is  developed  by  establishing  its  correctness  in  terms  of 

operators  which  manipulate  an  arbitrary  binary  tree  The  operators  and 

their  definitions  are  a  subset  Of  a  module  definition  due  to 

Parnas[PA2].  The  definitions  are  only  meant  to  be  descriptions  of  the 

general  capabilities  of  the  operators  which  will  be  implemented.  As  the 

envelopment  proceeds,  information  which  simplifies  these  implementations 

will  be  distributed  and  the  results  will  be  examined  using 

object/assumption  tables  and  the  measure. 

LS(i)  Left  Son(i) 

initial  value:  defined  prior  to  execution  of  the  algorithm  below, 
effect:  error  call  if  there  is  no  definition  of  the  left  son 

of  node  i;  otherwise  the  name  of  the  left  son  of 
node  i. 


RS(i) 


Right  Son(i) 


initial  value:  defined  prior  to  the  execution  of  the  algorithm 
below. 

effect:  error  call  if  there  is  no  definition  of  the  right 

son 

of  node  i;  otherwise  the  name  of  the  right  son  of 
node  i. 


ELS(i) 


Exists  Left  Gon(i) 
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possible  values:  true,  false 

effect:  error  call  if  node  i  has  no  direct  ancestor. 
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ERS(i)  Exists  Right  Son(i) 


possible  values:  true,  false 

effect:  error  call  if  node  i  has  no  direct  ancestor. 


VAL(i) 


VALue(i) 


initial  value:  set  prior  to  the  execution  of  the  algorithm  below, 
effect:  error  call  if  VAL(i)  is  undefined. 


SVAfi.v)  Set  Valued, v) 

This  function  has  no  value. 

effect:  error  call  of  node  i  has  no  direct  ancestor; 

otherwise  VAL<i)  =  v 


DEL(i)  DELete(i) 

This  function  has  no  value. 

effect:  error  call  if  i  has  no  direct  ancestor  or 

error  call  if  LSO)  or  RS(i)  are  undefined; 
otherwise  VAL(i)  becomes  undefined  and  i  is  never 
again  a  possible  value  of  RS  or  LS. 

Only  after  the  algorithm  is  developed,  are  the  implementations  of  the 
operators  described. 
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Below  is  a  map  describing  this  development. 


HEAPSORT 
:1:  (139) 


SVA(root,VAl(h)) 

DEUh) 


(2)  :3:  (161) 

Transform  tree  so  that  A(j) 
if  A(LS(j))  and  A(RS(j)) 


(n)  :2.1:  (153)  (0)  :2.2:  (154)  (p)  :2.3:  (154) 

VAL(K),  i  e.  SVA(j,K),  i.e.  ERS(j),  i.e. 

VAL  «-  TREE[k]  TREE[j]  x  ERS  «-  if  2*j+l  >  NN  then 

false  else  true 


(q)  :2.4:  (155)  (r)  :2.5:  (155) 

ELS(j)  i.e.  RS(j),  i.e. 
if  2*i  >  NN  then  RS  «-  2*j  +  1 
false  else  true 


(s)  :2.6:  (156)  (t)  -.2.7:  (156) 

LS(j),  i.e.  DEL(j),  i.e. 

LS  «-  2*j  NN  <-  NN  -  1 
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assumptior  s: 


effects  and 
post-conditions: 


(a)  : 1 . 1 : 

assumptions: 


effects  and 
post-conditions: 


requires  read  access  to  n,  the  number  of  nodes  in 
the  original  tree,  requires  read  access  to  n,  write 
access  required  for  the  elements  of  array  B, 
requires  DEL,  requires  VAL,  requires  LS,  requires 
RS,  requires  ELS,  requires  ERS 

:1:  GIVEN  A  BINARY  TREE,  HAVING  n  >  1  NODES  AND  A 
SET  OF  FUNCTIONS:  ERS,  ELS,  VAL,  LS,  RS,  SVA, 
DEL[PA2],  PRODUCE  AN  ARRAY  OF  VALUES,  B,  SUCH  THAT 
THERE  IS  A  ONE  TO  ONE  ONTO  MAPPING  FROM  THE  INITIAL 
VALUES  OF  THE  NODES  OF  THE  TREE  TO  THE  ELEMENTS  OF 
THE  ARRAY  B  AND  SUCH  THAT  THE  ELEMENTS  OF  THE  ARRAY 
ARE  ARRANGED  IN  ASCENDING  ORDER. 


Vi[l  <  i  <  n  3  B[i]  <  B[i+1]]  a  there  exists  a  one 
to  one  onto  mapping  from  .he  node  values  of  the 
initial  tree  to  the  elements  B[l],...,B[n]  of  the 
array 


A(i)  is  defined  to  be  Vx[(x  is  a  node  of  the  tree 
and  x  =  i  or  x  is  a  descendent  of  i)  3  ((ELS(x)  3 
VAL(x)  >  VAL(LS(x))  A  (ERS(x)  3  VAL(x)  > 
VAL(RS(x))))]  where  "x  is  a  descendent  of  i"  means 
"there  exists  a  composition  of  the  functions  LS  and 
RS,  say  C,  such  that  x  =  C(i),  requires  ERS, 

requires  ELS,  requires  RS,  requires  LS,  requires 
VAL,  requires  SVA,  root,  names  the  node  such  that 
every  node  which  is  not  root  is  a  descendent  of  root 
a  requires  read  access  to  root 

:  1. 1 :  TRANSFORM  THE  TREE  SUCH  THAT  A(root)  AND  THAT 
THERE  EXISTS  A  ONE  TO  ONE  ONTO  MAPPING  FROM  THE  NODE 
VALUES  OF  THE  INITIAL  TREE  TO  THE  CURRENT  NODE 
VALUES  OF  THE  TREE. 


A(root),  there  exists  a  one-one  onto  mapping  of  the 
node  values  of  the  initial  tree  to  the  current  node 
values 
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:  1 .2: 

assumptions: 


effects: 

post-conditions: 

(c)  :  1 .3: 

assumptions: 


effects  and 
post-conditions: 


requires  read  access  to  n,  requires  write  access  to 
the  integer  variable  i,  A(root),  there  exists  a 
one-one  onto  mapping  of  the  node  values  of  the 
initial  tree  to  the  current  node  values 

:  1 .2:  i  «-  n; 


i  =  n 

A(root),  there  exists  a  one-one  onto  mapping  of  the 
node  values  of  the  initial  tree  to  the  current  node 
values,  i  =  n 


Vj[i  <  j  <  n  ^  B[j]  <  B[j+1],  there  exists  a 
one-one  mapping  from  the  initial  contents  of  the 
tree  to  the  current  contents  of  the  tree  and  B[k],  i 
<  k  S  n,  A(root),  i  >  1  a  i  equals  the  number  of 
nodes  in  the  tree  a  post-conditions  for  :1.A:  => 
assumptions  for  :1.4:  a  i  is  decreased  by  1  at  each 
iteration,  requires  read  access  to  the  integer 
variable  i 

:  1 .3:  while  i  r1  1  do  :  1 . A: 


there  exists  a  one-one  mapping  from  the  initial 
contents  of  the  tree  to  the  current  contents  of  the 
tree  and  B[k],  i  <  k  <  n 
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(d)  :1.4: 

assumptions:  A(i)  is  defined  to  be  Vx[(x  is  a  node  of  the  tree 

and  x  =  i  or  x  is  a  descendent  of  i)  3  ((ELS(x)  3 

VAL(x)  >  VAL(LS(x))  a  (ERS(x)  =>  VAL(x)  > 

VAL(RS(x))»]  where  "x  is  a  descendent  of  i”  means 
"there  exists  a  composition  of  the  functions  LS  and 
RS,  say  C,  such  that  x  =  C(i),  requires  ERS, 

requires  ELS,  requires  RS,  requires  LS,  requires 
VAL,  requires  SVA,  requires  DEL,  write  access 

required  for  the  elements  of  array  B,  requires  read 
access  to  the  integer  variable  i,  requires  write 
access  to  the  integer  variable  i,  root,  names  the 

node  such  that  every  node  which  is  not  root  is  a 

descendent  of  root  a  requires  read  access  to  root, 

(ERS(i)  =>  A(RS(i)»  a  (ELS(i)  3  A(LS(i))),  Vj[i  <  j 

<  n  o  B[j]  <  B[j+1],  there  exists  a  one-one  mapping 
from  the  initial  contents  of  the  tree  to  the  current 
contents  of  the  tree  and  B[k],  i  <  k  <  n,  A(root) 

:  1.4:  TRANSFORM  THE  TREE  AND  B  SUCH  THAT  Vj[i  <  j  < 
n  3  B[j]  <  B[j  +  1]],  SUCH  THAT  THERE  EXISTS  A  ONE  TO 
ONE  MAPPING  FROM  THE  INITIAL  CONTENTS  OF  THE  TREE  TO 
THE  CURRENT  CONTENTS  OF  THE  TREE  AND  THE  ELEMENTS 
B[k],  i  <  k  <  n,  AND  THAT  A(root). 

effects  and 

post-conditions:  Vj[i  <  j  <  n  3  B[j]  <  B[j+1],  there  exists  a 

one-one  mapping  from  the  initial  contents  of  the 
tree  to  the  current  contents  of  the  tree  and  B[k],  i 

<  k  <  n,  A(root) 
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<•)  si. 5: 

assumptions:  requires  VAL,  root,  names  the  node  such  that  every 

node  which  is  not  root  is  a  descendent  of  root  a 
requires  read  access  to  root,  write  access  required 
for  the  elements  of  array  B,  there  exists  a  one-one 
mapping  from  the  initial  contents  of  the  tree  to  the 
current  contents  of  the  tree  and  B[K],  i  <  k  £  n, 
Vj[l  <  j  <  n  =  B[j]  <  B[j+ 1 33 

:  1 .5:  B[l]  «-  VAL(root); 

•ffacts:  B[l]  -  VAUroot) 

post-conditions:  Vi[l  <  i  <  n  ^  B[i]  <  B[i  +  1]]  a  there  exists  a  one 

to  one  onto  mapping  from  the  node  values  of  the 

initial  tree  to  the  elements  B[l] B[n]  of  the 

array 


' :  :i 
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123456789  101 1 12I314I5I6I7 1819202 1 2223242526272829303 1 

(a) 

l*  1  l  I  l  l  l  l  l  I 

I-  I*  1  1  1  1  1  1  1  1 

(b) 

1  •  2*  III 

1 

(c) 

1  •  3*  1  1  1 

1  1 

(d) 

1  •  4*  1  1  1  1  1  1  1  1  1  III  1  II 

1 

(e) 

1  •  5*  II  1  1 

l 

1) 

A(i)  is  defined  to  be 

Vx[(x  is  a  node  of  the  tree  and  x  =  i  or 

x  is  a  descendent  of  i)  3 

((ELS(x)  3  VAL(x)  >  VAL(LSfx))  a 

(ERS(x>  3  VAL(x)  >  VAL(RSfx))))] 

where  "x  is  a  descendent  of  i"  means  "there  exists  a 
composition  of  the  functions  LS  and  RS,  say  C, 

c 

.uch  that  x  =  C(i) 

2) 

requires  ERS 

3) 

requires  ELS 

4) 

requires  RS 

5) 

requires  LS 

6) 

requires  VAL 

7) 

requires  SVA 

8) 

requires  DEL 

9) 

write  access  required  for  the  elements  of 
array  B 

13)  requires  read  access  to  the  integer  variable  i 

14)  requires  write  access  to  the  integer  variable  i 

15)  root,  names  the  node  such  that  every  node 

which  is  not  root  is  a  descendent  of  root  a  requires 
read  access  to  root 

16)  requires  read  access  to  n 

17)  there  exists  a  one-one  onto  mapping  of  the 

node  values  of  the  initial  tree  to  the  current  node  values 
19)  (ERS(i)  3  A(RS<i )))  a  (ELS(i>  3  A(LS(i))) 

22)  Vj[i  <  j  <  n  3  B[j]  <  B[j+1] 

23)  there  exists  a  one-cne  mapping  from  the  initial  contents 
of  the  tree  to  the  current  contents  of  the  tree  and 
B[K],  i  <  k  <  n 

25)  A(root) 

30)  i  >  1  a  i  equals  the  number  of  nodes  in  the  tree  A 
post-conditions  for  :1.4:  3  assumptions  for  :1.4:  a 

i  is  decreased  by  1  at  each  iteration 

31)  Vj[i  <  j  <  n  3  B[j]  <  B[j  +  1]] 

there  exists  a  one-one  onto  mapping  of  the  initial 
tree  to  the  current  contents  of  the  tree  and 
B[K],  i  S  k  <  n 
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The  best  decomposition  is 

((a)  ((b)  (  c  ,  d  ,  •  ))  1.33  )  1.05 

and  any  further  decomposition  of  c,  d,  e  leads  to  an  entropy  loading  of 
1.61.  Hence,  for  this  decomposition,  saturation  has  occurred  for  (  c  , 
d  ,  «  ).  At  this  stage,  the  transformation  of  the  tree  so  that  A(root) 
interacts  least  with  the  other  objects.  Next,  :  1. 1 :  is  elaborated. 


(f)  : 1 . 1.2: 

assumptions:  ability  to  set  f  such  that  it  has  produced  no 

values  a  the  tree  is  finite  a  the  tree  contains  at 

least  one  node,  f  is  defined  to  be  the  value  i  such 

that  (i  has  not  been  produced  by  a  call  of  f  since  f 
was  last  initialized)  otherwise  the  value  of  f  is  0 

a  (the  nodes  of  the  tree  are  named  by  integers  which 
are  not  equal  to  0),  requires  write  access  to  the 
integer  variable  i 

:  1 .1.2:  INITIALIZE  f;  i  <-  f; 


effects  and 

post-conditions:  i  names  a  node  such  that  for  this  execution  of  the 

while  construct,  for  all  previous  values  held  by  i, 
A(i)  A  i  has  not  held  the  current  value  a  if  i  has 
named  all  the  nodes  then  i  =  0 
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<g)  :  1 . 1.3: 
assumptions: 


offsets: 

post-conditions: 


requires  read  access  to  the  integer  variable  i, 
root,  names  the  node  such  that  every  node  which  is 
not  root  is  a  descendent  of  root  a  requires  read 
access  to  root,  f  is  defined  to  be  the  value  i  such 
that  (i  has  not  been  produced  by  a  call  of  f  since  f 
was  last  initialized)  otherwise  the  value  of  f  is  0 
a  (the  nodes  of  the  tree  are  named  by  integers  which 
are  not  equal  to  0)  (if  ERS(i)  then  A(RS(i)) 
true)  a  (if  ELS(i)  then  A(LS(i))  else  true)  ,  i 
names  a  node  such  that  for  this  execution  of  the 
while  construct,  for  all  previous  values  held  by  i, 
A(i)  a  i  has  not  held  the  current  value  a  if  i  has 
named  all  the  nodes  then  i  ■  0 

:  1 . 1 .3:  while  i  r4  0  do 

begin 

:1.1.4:  i  : 1.1.5: 

end 

i  =  0,  i  names  a  node  such  that  for  this  execution 
of  the  while  construct,  for  all  previous  values  held 
by  i,  A(i)  a  i  has  not  held  the  current  value  a  if  i 
has  named  all  the  nodes  then  i  =  0 

there  exists  a  one-one  onto  mapping  of  the  node 
values  ot  the  initial  tree  to  the  current  node 
values,  A(i  oot) 
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(h)  :1.1.4: 
assumptions: 


effects  and 
post-conditions: 

(i)  :  1 . 1 .5: 
assumptions: 


effects  and 
post-conditions: 


(ERS(i)  =  A(RS(i»>  a  (ELS(i)  3  A(LS(i)»,  requires 
read  access  to  the  integer  variable  i,  A(i)  is 
defined  to  be  Vx[(x  is  a  node  of  the  tree  and  x  «  i 
or  x  is  a  descendent  of  i)  3  ((ELS(x)  3  VAL(x)  2 
VAL(LS(x))  a  (ERS(x)  3  VAL(x)  >  VAL(RS(x))»]  where 
"x  is  a  descendent  of  i"  means  "there  exists  a 
composition  of  the  functions  LS  and  RS,  say  C,  such 
that  x  =  C(i),  requires  ERS,  requires  ELS,  requires 
RS,  requires  LS,  requires  VAL,  requires  SVA 

:1.1.4:  MODIFY  THE  TREE  SUCH  THAT  A(i)  AND  THAT  THE 
NODE  VALUES  ARE  PERMUTED. 


A(i),  there  exists  a  one-one  onto  mapping  of  the 
node  values  of  the  initial  tree  to  the  current  node 
values 


f  is  defined  to  be  the  value  i  such  that  (i  has  not 
been  produced  by  a  call  of  f  since  f  was  last 
initialized)  otherwise  the  value  of  f  is  0  a  (the 
nodes  Of  the  tree  are  named  by  integers  which  are 
not  equal  to  0)  (if  ERS(i)  then  A(RS(i»  else  true) 
a  (if  ELS(i)  then  A(LS(i)>  else  true)  ,  requires 
write  access  to  the  integer  variable  i 

:1.1.5:  i  «-  fi 


i  names  a  node  such  that  for  this  execution  of  the 
while  construct,  for  all  previous  values  held  by  i, 
A(i)  A  i  has  not  held  the  current  value  a  if  i  has 
named  all  the  nodes  then  i  =  0 
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The  object  assumption  table  is  now 

123456789  101 1 12131^151617 1819202 12223242526272829303 1 3233 
:  | :  l  i  i  i  i  i  i  i  > 

(a)  :  i ■  i :  I  I  I  I  I  I  I  I 

(b)  s,.2:  l  1  '  1 

(c)  :  i . 3s  I  1  1  1  1 

(d)  :  | .  4:  M  M  1  1  1  1  1  i>i  1  11  1 

(e)  : 5:  I'  1  1  ‘ 

(f)  : 2*.  II  1 

(g)  s  |.  i- 3*  1  l  I  l  1 

(h)  :  1 .  1 . 4:  1  1  1  1  1  1  1  1  1 

(i)  s  1.1.5s  1  1  1 

1)  A(i)  is  defined  to  be 

Vx[(x  is  a  node  of  the  tree  and  x  -  i  or 
x  is  a  descendent  of  i)  ^ 

(( ELS(x)  3  VALK  *  VAL(LS(x))  A 
(ERS(x)  3  VAKx;  >  VAL(RS(x))))] 
where  "x  is  a  descendent  of  i"  means  "there  exists  a 
composition  of  the  functions  LS  and  RS,  say  C, 
such  that  x  «=  C(i) 

2)  requires  ERS 

3)  requires  ELS 

4)  requires  RS 

5)  requires  LS 

6)  requires  VAL 

7)  requires  SVA 

8)  requires  DEL 

9)  write  access  required  for  the  elements  of 
array  B 

10)  f  is  defined  to  be  the  value  1  such  that 

(1  has  not  been  produced  by  a  call  of  f  since  f  was  last 
initialized)  otherwise  the  value  of  f  is  0  a 
(the  nodes  of  the  tree  are  named  by  integers  which  are 
not  equal  to  0) 

11)  (ERS(i)  =>  A(RS(i)))  a  (ELS(i)  =  A(LS(i)» 

13)  requires  read  access  to  the  integer  variable  i 

14)  requires  write  access  to  the  integer  variable  i 

15)  root,  names  the  node  such  that  every  node 

which  is  not  root  is  a  descendent  of  root  a  requires 
read  access  to  root 

16)  requires  read  access  to  n,  the  number  of  nodes  in  the 
original  tree 

17)  there  exists  a  one-one  onto  mapping  of  the 

node  values  of  the  initial  tree  to  the  current  node  values 
19)  (ERS(root)  o  A(RS(root)))  a  (ELS(root)  =  A(LS(root))) 

21)  ability  to  set  f  such  that  it  has  produced  no  values  a 
the  tree  is  finite  a 
the  tree  contains  at  least  one  node 
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22)  Vj[i  <j<n  =  B[j]  <  B[j+1] 

23)  there  exists  a  one-one  mapping  from  the  initial  contents 
of  the  tree  to  the  current  contents  of  the  tree  and 
B[k],  i  <  k  <,  n 

25)  A(root) 

30)  i  £  1  a  i  equals  the  number  of  nodes  in  the  tree  a 
post-conditions  for  :i.4:  3  assumptions  for  :1.4:  A 

i  is  decreased  by  1  at  each  iteration 

31)  Vj[l  <  j  <  n  a  B[j]  <  B[j  +  1]] 

there  exists  a  one-one  onto  mapping  of  the  initial 
tree  to  the  current  contents  of  the  tree  and 
B[k],  i  <  k  <  n 

33)  i  names  a  node  such  that 

for  this  execution  of  the  while  construct, 
for  all  previous  values  held  by  i,  A(i)  A 
i  has  not  held  the  current  value  a  if  i  has  named 
all  the  nodes  then  i  *  0 

RLB  and  RUB  are 


RLB:  <(«>  ((b)  (  c  ,  d  ,  •  ))  1.07  )  0.0 
RUB:  ((a)  ((b)  (  c  ,  d  ,  e  ))  1.07  )  .90 
But  the  acutal  elaboration  has  entropy  loadings 

((  1  ,  g  .  h  ,  i  )  ((  b  )  (  c  ,  d  ,  e  ))  1.49  )  1.91 
One  reason  for  this  marked  increase  in  entropy  loading  values  is  that 
information  about  the  variable  i  is  shared  between  parts  where  such 
sharing  did  not  occur  at  the  last  stage.  A  better  decomposition  is 
((f)  ((b)  ((e)  ((c)  «i)  ((d)  (  g  ,  h  )) 

1.91  )  1.73  )  1.73  )  1.67  )  1.49  )  1.49 

Unfortunately,  this  decomposition,  though  better,  seems  arbitrary. 
Here,  (f)  [i  «-  f]  interacts  least,  ut  (g)  and  (h)  that  help  transform 
the  tree  so  that  A(root),  interacts  most.  In  this  instance,  the 
decomposition  suggested  by  the  last  stage  is  not  a  good  one  at  this 


stage. 
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Next,  :1.4:  is  elaborated. 


(j)  :  1.4.1: 

assumptions:  write  access  required  for  the  elements  of  array  B, 

requires  VAL,  requires  read  access  to  the  integer 
variable  i,  root,  names  the  node  such  that  every 
node  which  is  not  root  is  a  descendent  of  root  a 
requires  read  access  to  root 

:  1.4.1:  B[i]  «-  VAL(root); 

effects:  B[i]  “  VAL(root) 


effects  and 
post-conditions: 

(k)  :  1.4.2: 
assumptions: 


there  exists  a  one-one  mapping  from  the  initial 
contents  of  the  tree  to  the  current  contents  of  the 
tree  and  B[k],  i  <  K  <  n 


requires  read  access  to  h,  there  exists  a  one-one 
mapping  from  the  initial  contents  of  the  tree  to  the 

current  contents  of  the  tree  and  B[k],  i  <  k  <  n, 
requires  write  access  to  h,  root,  names  the  node 
such  that  every  node  which  is  not  root  is  a 

descendent  of  root  a  requires  read  access  to  root, 
requires  VAL,  requires  SVA,  requires  DEL,  there 

exists  a  function  g  which  names  a  node,  i,  such  that 

NOT(ERS(i)  v  ELS(i» 


:  1.4.2:  h  «-  g;  SVA(root,  VAL(h));  DEL(h); 

effects  and  .  „  .. 

post-conditions:  there  exists  a  one-one  onto  mapping  from 

initial  nodes  of  the  tree  to  the  current  nodes  of 

the  tree  and  B[kJ,  i  <  k  S  n 
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(I)  :1A3: 
assumptions: 


effects  and 
post-conditions: 

(m)  ilAAi 
assumptions: 


effects  and 
post-conditions: 


A(i)  is  defined  to  be  Vx[(x  is  a  node  of  the  tree 
and  x  -  i  or  x  is  a  descendent  of  i)  ^  <(ELS(x)  o 
VAL(x)  >  VAL(L$(x))  a  (ERS(x)  o  VAL(x)  > 
VAL(RS{x)»)]  where  "x  is  a  descendent  of  i"  means 
"there  exists  a  composition  of  the  functions  LS  and 
RS,  say  C,  such  that  x  =  C(i),  requires  ERS, 

requires  ELS,  requires  RS,  requires  LS,  requires 
VAL,  requires  SVA,  (ERS(i)  =>  A(RS(i)))  A  (ELS(i)  => 
A(LS(i)M 

:1.4.3:  MODIFY  THE  TREE  SUCH  THAT  A(root)  AND  THAT 
THE  NODE  VALUES  ARE  PERMUTED 


A(root),  Vj[i  <  j  <  n  ^  B[j]  5  B[j+1]  a  there 
exists  a  one-one  onto  mapping  of  the  initial  tree  to 
the  current  contents  of  the  tree  and  B[k],  i  S  k  <  n 


requires  read  access  to  the  integer  variable  i, 
requires  write  access  to  the  integer  variable  i, 
A(root),  Vj[i  <  j  <  n  3  B[j]  <  B[j+1]  a  there  exists 
a  one-one  onto  mapping  of  the  initial  tree  to  the 
current  contents  of  the  tree  and  B[k],  i  £  k  <  n 

:  1 .4.4:  i  <-  i  -  1; 


Vj[i  <  j  <  n  3  B[j]  <  B[j+1],  there  exists  a 
one-one  mapping  from  the  initial  contents  of  the 
tree  to  the  current  contents  ot  the  tree  and  B[k],  i 
<  k  <  n,  A(root) 


USING  THE  MEASURE 
HEAPSORT 


151 


Below  is  the  object/assumption  table  for  this  elaboration 


(j) 

00 

0) 

(m) 


1-4-  I  • 
I •  4.  25 
!•  4-  3: 
!•  <*■  45 


I  23456789  1011 1 2 13 14 1 51 61 7 1 81 9202 1 2223242526272829303 132 

II  II 

III  I  till 

I  I  I  I  I  I  I  I  I 

II  I  I 


1)  A(i)  is  defined  to  be 

Vx[(x  is  a  node  of  the  tree  and  x  *  i  or 
x  is  a  descendent  of  i)  ^ 

((ELS(x)  =  VAL(x)  >  VAL<LS(x))  a 
(ERS(x)  =  VAL(x)  >  VAL(RS(x))))] 
where  "x  is  a  descendent  of  i"  means  "there  exists  a 
composition  of  the  functions  LS  and  RS,  say  C, 
such  that  x  =  C(i) 

2)  requires  ERS 

3)  requires  ELS 

A)  requires  RS 

5)  requires  LS 

6)  requires  VAL 

7)  requires  SVA 

8)  requires  DEL 

9)  write  access  required  for  the  elements  of 
array  B 

13)  requires  read  access  to  the  integer  variable  i 

14)  requires  write  access  to  the  integer  variable  i 

15)  root,  names  the  node  such  that  every  node 

which  is  not  root  is  a  descendent  of  root  a  requires 
read  access  to  the  variable  root 
19)  (ERS(root)  o  AfRS(root)))  a  (ELS(root)  =  A(LS(root))) 

23)  there  exists  a  one-one  mapping  from  the  initial  contents 
of  the  tree  to  the  current  contents  of  the  tree  and 
B[k],  i  <  k  <  n 

25)  A(root) 

26)  there  exists  a  function  g  which  names  a  node,  i,  such 
that  N0T(ERS(i)  v  ELS(i)) 

27)  requires  read  access  to  h 

28)  requires  write  access  to  h 
32)  Vj[i  <  j  <  n  s  B[j]  <  B[j+1]  a 

there  exists  a  one-one  onto  mapping  of  the  initial 
tree  to  the  current  contents  of  the  tree  and 
B[k],  i  <  k  <  n 


RLB  and  RUB  for  this  elaboration  are 


RLB:  ((f)  ((b)  «•)  ((c)  «i)  ((d)  (  g  ,  h  )) 


0.0  )  1.19  )  1.29  )  1.16  )  1.03  )  1.16 
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RUB:  ((f)  ((b)  ((e)  ((c)  ((i)  ((d)  (  g  ,  h  » 

1.77  )  1.54  )  1.64  )  1.59  )  1.47  )  1.37 
The  actucal  entropy  loadings  are 

((f)  ((b)  ((e)  ((c)  «i)  «  j  ,  k  ,  I  ,  m  ) 

(  g  ,  h  ))  2.15  )  1.54  )  1.67  )  1.89  )  1.29  )  1.29 
A  better  decomposition  is 

((f)  ((b)  ((e)  «i)  ((c)  «m)  «  k  ,  i  )  ((j)  (  g  ,  h  )) 

1.85  )  1.77  )  1.67  )  1.67  )  1.54  )  1.54  )  1.29  )  1.29 

The  algorithm  to  this  stage  of  development  represents  a  solution  to 
the  problem  as  it  was  originally  posed.  Next,  an  implementation 
decision  is  made  which  has  the  potential  for  simplifying  the 
construction  of  the  functions  f  and  g  as  well  as  the  functions  which 
operate  on  the  tree.  This  decision  represents  the  original  n  nodes  in 
the  array  elements  TREE[  1  TREE[n],  where  the  names  of  the  nodes 

are  their  array  indices  and  for  1  <  k  <  n,  IS(  k  div  2  )  ■*  k  if  k  is 
cvon  and  RS(  k  div  2  )  =  k  if  k  is  odd  and  VAL(k)  -  TREE[k].  This 
representation  has  several  important  properties: 

(a)  ERS(k)  ^  ELS(k) 

(b)  If  TREE  contains  m  >  1  elements  (nodes)  in  TREE[1  ],..., 

TREE[m]  then  ERS(k)  is  defined  to  be  2*k  +  1  <  m  and  ELS(k)  is 

defined  to  be  2*k  £  m  for  positive  integer  k. 

(c)  if  TREE  contains  m  >  1  elements  (nodes)  in  TREE[1  ],..., 

TRtE(m]  and  m  is  a  variable  which  indicates  the  number  of 

elements  in  the  tree,  DEL(m)  is  accomplished  by  the  assignment 
m  «-  m  -  1. 
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(d)  (  ELS(k)  o  (LS(k)  «=  2*k  ))  a  (  ERS(k)  3  (  RS(k)  =  2*k  +  1  )). 
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These  properties  also  simplify  the  construction  of  f  and  g. 
Specifically,  <  is  called  only  after  a  previous  call  of  I,  whose  value 
is  f has  been  used  to  transform  the  tree  such  that  A(f’).  Hence, 

:  1.1,2:  INITIALIZE  f;  i  «-  f; 

can  be  written  as 

i  «-  f  «-  n  div  2; 

and 

:  1 . 1 .5:  i  <-  f; 

can  be  written  as 

i  «-  f  «-  f  -  1; 

since  A(k)  is  vacuously  tiue  if  k  is  a  terminal  node  of  the  tree. 

Similarly,  the  function  g  can  be  defined  to  equal  the  value  of  i  as 
defined  in  :1.2:  and  decremented  in  :1.4.4: 

Lastly,  the  definition  of  root  is  1  which  indicates  that  TREE[1]  is 
the  root  node  of  the  tree. 

These  properties  together  provide  definitions  for  the  tree 
operations  as  follows 

(n)  :2.1: 

assumptions:  TREE  is  a  one-dimensional  array  containing  n 

elements,  i.e.  TREE[1  ],...,  TREE[n],  and  contains 
the  representation  of  the  tree  in  the  form  RS(j)  = 
TREE[2*j  +  1]  and  LS(j)  =  TREE[2*j],  assumes  read 
access  to  TREE,  parameter  for  VAL  is  always  legal 

: 2 . 1 :  COMPUTE  VAL(k),  i.e.  VAL  <-  TREE[k]; 

effects  and 

post-conditions:  VAL  equals  the  value  of  node  k  in  the  tree 
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(O)  :2.2: 


assumptions: 


effects  and 
post-conditions: 


(p)  :2.3: 
assumptions: 


effects  and 
post-conditions: 


TREE  is  a  one-dimensional  array  containing  n 

elements,  i.e.  TREE[1] .  TREE[n],  and  contains 

the  representation  of  the  tree  in  the  form  RS(j)  • 
TREE[2*j  +  1]  and  LS(j)  -  TREE[2*j],  assumes  write 
access  to  TREE,  j  names  an  integer  in  the  range  1  to 
n  and  it  is  meaningful  to  assign  x  to  an  element  of 
TREE 

:2.2:  COMPUTE  SVA(j.x),  i.e.  TREE[j]  ♦-  x; 


the  value  of  x  has  been  assigned  to  node  j 


TREE  is  a  one-dimensional  array  containing  n 

elements,  i.e.  TREE[1] .  TREE[n],  and  contains 

the  representation  of  the  tree  in  the  form  RS(j) 
TREE[2*j  +  1]  and  LS(j)  =  TREE[2*j],  parameter  for 
ERS  is  a  positive  integer,  requires  read  access  to 
the  variable  NN,  NN  indicates  the  number  of  nodes 
currently  in  TREE,  such  that  TREE[i],  1  S  i  S  NN  is 
a  node  of  the  tree 

:2.3:  COMPUTE  ERS(j)  i.e.  ERS  «-  if  2*j  +  1  NN 

then  false  else  true; 


ERS  «  the  value  "there  exists  a  right  son  of  j" 
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(q)  :2 A: 

assumptions:  TREE  is  a  one-dimensional  array  containing  n 

elements,  i.e.  TREE[1  TREE[n],  and  contains 

the  representation  of  the  tree  in  the  form  RS(j)  = 
TREE[2*j  +  1]  and  LS(j)  =  TREE[2*j],  parameter  for 
ELS  is  a  positive  integer  ,  requires  read  access  to 
the  variable  NN,  NN  indicates  the  number  of  nodes 
currently  in  TREE,  such  that  TREE[i],  1  <>  i  <  NN  is 
a  node  of  the  tree 

:2 .4:  COMPUTE  ELS(j)  i.e.  ELS  <-  if  2*j  >  NN  then 

false  else  true; 

effects  and 

post-conditions:  ELS  equals  the  value  of  “there  exists  a  left  son  of 

r 

(r)  :2.5: 

assumptions:  TREE  is  a  one-dimensional  array  containing  n 

elements,  i.e.  TREE[1],...,  TREE[n],  and  contains 
the  representation  of  the  tree  in  the  form  RS(j)  * 
TREE[2*j  +  1]  and  LS(j)  =  TREE[2*j],  parameter  for 
RS  is  legal  for  the  current  state  of  the  TREE 

:2.5:  COMPUTE  RS(j),  i.e.  RS  «-  2*j  +  1 

effects  and 

post-conditions:  RS  equals  the  index  of  the  right  son  of  j 
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(s)  :2.6: 

assumptions:  TREE  is  a  one-dimensional  srray  containing  n 

elements,  i.e.  TREE[1],...,  TFEE[n],  and  contains 

the  representation  of  the  tree  in  the  form  RS(j)  * 
TREE[2*j  +  1]  and  LS(j)  -  TREE[2*j],  parameter  for 

LS  is  meaningful 

:2.6:  COMPUTE  LS(j)  i.e.  LS  ♦-  2*j 

effects  and 

post-conditions:  LS  equals  the  index  of  the  left  son  of  j 

(t)  :2.7: 

assumptions:  TREE  is  a  one-dimensional  array  containing  n 

elements,  i.e.  TREE[1],...,  TREE[n],  and  contains 

the  representation  of  the  tree  in  the  form  RS(j)  = 
TREE[2*j  +  1]  and  LS(j)  =  TREE[2*j],  parameter  for 

DEL  always  names  the  current  alue  in  NN,  requires 

read  access  to  the  variable  NN,  requires  write 

access  to  the  variable  NN,  NN  indicates  the  number 
of  nodes  currently  in  TREE,  such  that  TREEfi],  1  £  i 
<  NN  is  a  node  of  the  tree 

:2.7:  COMPUTE  DEL(j)  i.e.  NN  ♦-  NN  -1; 

effects  and 

post-conditions:  node  j  has  been  deleted  from  the  tree 
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The  object/assumption  table  for  this  elaboration  is: 


(n) 

•  2'  1 

(o> 

•  2'  2 

(P) 

•  2'  3 

(q) 

*•2  4 

(r) 

:2.  5 

(s) 

'2-  6 

(t) 

:  2-  7 

34353637383940014243044546 
I  I  I 
I  i  I 

1  1  11 
I  111 

I  I 

I  I 

I  I  I  I  I 


34)  TREE  is^  cne -dimensional  array  containing  n  elements,  i.e. 
TREE[1  TREE[n],  and  contains  the  representation  of  the 
tree  in  tjie  form  RS(j)  ■  TREE[2*j  +  1]  and 

LS(j)  =  7REE[2*j] 

35)  assumes  read  access  to  TREE 

36)  assumes  write  access  to  TREE 

37)  parameter  for  VAL  is  always  legal 

38)  j  names  an  integer  in  the  range  1  to  n  and 

it  is  meaningful  to  assign  x  to  an  element  of  TREE 

39)  parameter  for  ERS  is  a  positive  integer 

40)  parameter  for  ELS  is  a  positive  integer 

41)  parameter  for  RS  is  legal  for  the  current  state  of  the  TREE 

42)  parameter  for  LS  is  legal 

43)  parameter  for  DEL  always  names  the  current  value  in  NN 

44)  requires  read  access  to  the  variable  NN 

45)  requires  write  access  to  the  variable  NN 

46)  NN  indicates  the  number  of  nodes  currently  in  TREE,  such 
that  TREE[i],  1  <  i  <  NN  is  a  node  of  the  tree 


A  good  decomposition  of  this  development  is 


<(*)  «f)  «b)  (0)  «i)  ((c)  <(m)  ((  k  ,  e  )  ((j) 

(  g  ,  h  ))  1.42  )  1.39  )  1.39  )  1.28  )  1.20  )  1.16  )  .96  )  .96  )  .67 


where 


*:  «n)  ((o)  «r)  <(s)  (  t  ,  p  ,  q  )  .70  )  .72  )  .75  )  .83 
The  addition  of  these  new  objects  improves  the  entropy  loadings  for  the 
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former  decomposition. 
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The  objects  which 

(u)  :1. 1.2.1: 

assumptions: 


effects  and 
post-conditions: 

(v)  :1. 1.5.1: 
assumptions: 


effects  and 
post-conditions: 


elaborate  the  definitions  of  f  and  g  are: 


<  is  called  only  after  the  immediately  preceding 

call  of  f,  whose  value  is  f’,  has  been  used  to 

transform  the  tree  such  that  A(f’)  a  the  sequence  of 

values  n  div  2,  0  is  a  sequence  of  node  value 

which  satisfy  all  the  assumptions  of  :1.1.4:,  read 

access  required  for  f,  TREE  is  a  one-dimensional 
array  containing  n  elements,  i.e.  TREE[1],.., 
TREE[n],  and  contains  the  representation  of  the  tree 

in  the  form  RS(j)  =  TREE[2*j  +  1]  and  LS(j)  *= 

TREE[2*j],  requires  write  access  to  the  integer 
variable  i,  requires  read  access  to  n,  the  number  of 

nodes  in  the  original  tree, 

:1. 1.2.1:  i  <-  <  <-  n  div  2; 


i  names  a  node  such  that  for  this  execution  of  the 
while  construct,  for  all  previous  values  held  by  i, 
A(i)  a  i  has  not  held  the  current  value  a  if  i  has 
named  all  the  nodes  then  i  -  0,  (ERS(i)  A(RS(i))) 
a  (ELS(i)  =»  A(LS(i))) 


<  is  called  on.y  after  the  immediately  preceding 
call  of  f,  whosp  value  is  f\  has  b  en  used  to 
transform  the  tree  such  that  A(f’)  a  the  sequence  of 

values  n  div  2,  ...,  0  is  a  sequence  of  node  value 

which  satisfy  all  the  assumptions  of  :1  1.4:,  read 

access  required  for  f,  write  access  required  for  f, 
TREE  is  a  one-cnmensional  array  containing  n 

elements,  i.e.  T  REE[  1 TREE[n],  and  contains 
the  representation  of  the  tree  in  the  form  RS(j)  = 
TREE[2»j  ♦  1]  and  LS(j)  =  TREE[2*j],  requires  read 
access  to  n,  the  number  of  nodes  in  the  original 
tree 

:  1. 1.5.1:  i  -  f  -  f  -  li 


i  names  a  node  such  that  for  this  execution  of  the 
while  construct,  for  all  previous  values  held  by  i, 
A(i)  a  i  has  not  held  the  current  value  a  if  i  has 
named  all  the  nodes  then  i  =  0 
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(w)  :1. 4.2.1: 

assumptions:  requires  read  access  to  h,  requires  write  access  to 

h,  there  exists  a  one-one  mapping  from  the  initial 
contents  of  the  tree  to  the  current  contents  of  the 

tree  and  B[k],  i  <  k  <  n,  root,  names  the  node  such 
that  every  node  which  is  rot  root  is  a  descendent  of 
root  a  requires  read  recess  to  the  variable  root, 
requires  VAL,  requires  SVA,  requires  DEL,  TREE  is  a 

one-dimensional  array  containing  n  elements,  i.e. 

TREEfl  ],...,  TREE[n],  and  contains  the 
representation  of  the  tree  in  the  form  RS(j)  = 
TREE[2*j  +  1]  and  LS(j)  -  TREE[2*j],  the  number  of 
elements  in  the  tree  equals  the  value  of  i.  Hence 

node  i  has  no  descendants,  requires  read  access  to 

the  integer  variable  i 

:1  A2.1:  h  *-  i;  SVA(root,VAL(h));  DEL(h); 

effects  and 

post-conditions:  there  exists  a  one-one  onto  mapping  from  the 

initial  nodes  of  the  tree  to  the  current  nodes  of 
the  tree  and  B[k],  i  <  k  <  n 

Lastly,  most  of  the  tree  operations  can  be  localized  to  one  object  by 
making  the  following  elaborations: 

(x)  : 1.1. 4.1: 

assumptions:  the  assumptions  of  :1.1.4:  o  (there  ex:sts  a 

procedure,  siftup(j),  whicn  assumes  that  (ELS(j)  ^ 
A(LS<  j )))  A  (ERS(j)  ^  A(RS(j)))  and  results  in  AU 
(ERS(i)  ^  A(RS(i)»  a  (EuS(i)  =>  A(LSh)j),  requires 
read  access  to  tho  integer  variabio  i 

:1. 1.4.1:  siftup(i); 

effects  and 

post-conditions:  A(i),  there  exists  a  one-one  onto  mapping  of  the 

node  values  of  the  initial  tree  to  the  current  node 
values 
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(y)  :  1.4.3. 1: 
assumptions: 


•(facts  and 
post-conditions: 


the  assumptions  o(  :1A3:  3  (there  exists  a 
procedure,  siftup(j),  which  assumes  that  (ELS(j)  3 
A(LS( j )))  a  (ERS(j)  3  A(RS(j)))  and  results  in  A(j)) 
,  root,  names  the  node  such  that  every  node  which  is 
not  root  is  a  descendent  of  root  a  requires  read 

access  to  the  variable  root,  (ERS(root)  3 

A(RS(root)))  A  (ELS(root)  3  A(LS(root))) 

:1. 4.3.1:  siftup(root); 


A(root),  Vj[i  S  j  <  n  3  B[j]  <  B[j+1]  a  there 
exists  a  one-one  onto  mapping  of  the  initial  tree  to 
the  current  contents  of  the  tree  and  B[k],  i  <  k  <  n 
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(z)  :3: 

assumptions:  (ERS(i)  3  A(RS(i)))  a  (ELS(i)  =>  A(LS(i))),  ERS(i)  => 

ELS(i),  assumes  read/write  access  to  NOLOOP,  j,  t, 
copy,  requires  ERS,  requires  ELS,  A(i)  is  defined  to 
be  Vx[(x  is  a  node  of  the  tree  and  x  -  i  or  x  is  a 
descendent  of  i)  =>  ((ELS(x)  3  VAL(x)  >  VAL(LS(x))  a 
(ERS(x)  3  VAL(x)  ;>  VAL(RS'x))))]  where  Hx  is  a 
descendent  of  i"  means  "there  exists  a  composition 
of  the  functions  LS  and  RS,  say  C,  such  that  x  «* 
C(i),  requires  RS,  requires  LS,  requires  VAL, 

requires  SVA,  (ELS(j)  3  A(LS(j)))  a  (ERS(j)  3 

A(RS(j))) 

:3:  siftup(j): 
copy  *-  VAL(j); 

repeat 

begin 

NOLOOP  true; 
if  ELS(j)  then 
begin 

if  ERS(j)  then 
begin 

if  VAL(  RS(j)  )  >  VAL(  LS(j)  )  then 
t  -  RS(j) 

else 

t  LS(j) 

end; 

if  VAu(t)  >  copy  then 
begin 

SVA(j,  VAL(t)); 
t  *•  t; 

NOLOOP  *•  false; 
end 
end 

end 

until  NOLOOP; 

SVA(j,  copy); 


effects  and 
post-conditions: 


A(the  value  of  j  on  entry  to  sif tup) 
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The  object  assumption  table  for  these  additional  objects  is 


(u) 

1  •  1-2-  1 

(V) 

1  •  1-5-  1 

(w) 

114  1 

(x) 

1  •  4-  2-  1 

(y) 

1  4  3  1 

(z) 

3: 

(u) 

hi  21 

(V) 

1  •  1-5-  1 

(w) 

1  •  14  1 

(x) 

I-  4-  2-  1 

(y) 

1  -  4-  3-  1 

(z) 

3* 

I  23456789  1011 1 2 1 3 k 4 1 5 1 6 1 7 1 8 1 9202 1 2223242526272329 

I  I 
I 

I  I 

III  II  I  II 

I  I 

I  I  I  1  I  I  I  I 

3  4  3  5363  73  83  9404 1 4243444546474  849505 1 5  2  53  5455 
I  I  I 

I  III 

I 


I  I 


1)  A(i)  is  defined  to  be 

Vx[(x  is  a  node  of  the  tree  and  x  =  i  or 
x  is  a  descendent  of  i)  3 
((ElS(x)  o  VAL(x)  >  VAL(lS(x))  a 
(ERS(x)  o  VAL(x)  >  VAL(RS(x))))] 
where  "x  is  n  descendent  of  i"  means  "there  exists  a 
composition  of  the  functions  LS  and  RS,  say  C, 
such  that  x  =  CO) 

2)  requires  ERS 

3)  requires  ELS 

4)  requires  R3 

5)  requires  LS 

6)  requires  VAL 

7)  requires  SVA 

8)  requires  DEL 

9)  write  access  required  for  the  elements  of 
array  b 

10)  f  is  defined  to  be  the  value  i  such  that 

(i  has  not  been  produced  by  a  call  of  f  since  f  was  last 
initialized)  otherwise  the  value  of  f  is  0  a 
(the  nodes  of  the  tree  are  named  by  integers  which  are 
not  equal  to  0) 

11)  (ERS(i)  3  A(RSO)))  a  (ELS(i)  =  A(LS(i))) 

12)  there  exists  a  one-one  onto  mapping  of  the  node 
values  prior  to  the  transformation  to  the  node 
values  after 

13)  requires  read  access  to  the  integer  variable  i 

14)  requires  write  access  to  the  integer  variable  i 

15)  rool,  names  the  node  such  that  every  node 

which  is  not  root  is  a  descendent  Of  root  a  requires 
read  access  to  the  variable  root 

16)  requires  read  access  to  n,  the  number  of  nodes  in  the 
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original  tree 

17)  there  exists  a  one-one  onto  mapping  of  the 

node  values  of  the  initial  tree  to  the  current  node  values 

18)  i  -  n 

19)  (ERS(root)  s  A(RS(root)))  a  (ELS(root)  o  A(LS(root») 

20)  A(i) 

21)  ability  to  set  f  such  that  it  has  produced  no  values  a 
the  tree  is  finite  a 

the  tree  contains  at  least  One  node 

22)  Vj[i  <  j  <  n  a  B[j]  $  B[j  +  1] 

23)  there  exists  a  one-one  mapping  from  the  initial  contents 
of  the  tree  to  the  current  contents  of  the  tree  and 
B[k],  i  <  k  <  n 

24)  (ERS(root)  3  A(RStroot)))  a  (ELS(root)  3  A(LS(root))) 

25)  A(root) 

26)  there  exists  a  function  g  which  names  a  node,  i,  such 
that  NOTtERSO)  v  ELS(i)) 

27)  requires  read  access  to  h 

28)  requires  write  access  to  h 

29)  there  exists  a  one-one  onto  mapping  trom  the 
initial  nodes  of  the  tree  to 

the  current  nodes  of  the  tree  and  B[k],  i  <  k  <  n 

30)  i  >  1  a  i  equals  the  number  of  nodes  in  the  tree  a 
post-conditions  for  :1.4:  3  assumptions  for  :1.4:  a 

i  is  decreased  by  1  at  each  iteration 

31)  Vj[l  <  j  <  n  d  B[j]  <  Btj+1]] 

32)  Vj[i  S  j  <  n  s  B[j]  <  B[j+1]  a 

there  exists  a  one-one  onto  mapping  of  the  initial 
tree  to  the  current  contents  of  the  tree  and 
B[k],  i  <  k  <  n 

33)  i  names  a  node  such  that 

for  this  execution  of  the  while  construct, 
for  all  previous  values  held  by  i,  A(i)  a 
i  has  not  held  the  current  value  A  If  i  has  named 
all  the  nodes  then  i  =  0 

34)  TREE  is  a  one-dimensional  array  containing  n  elements,  i.e. 
TREE[i ],...,  TREE[n],  and  contains  the  representation  of  the 
tree  in  the  form  RS(j)  =  TREE[2*j  +  1]  and 

LS(j)  =  TREE[2*j] 

35)  assumes  read  access  to  TREE 

36)  assumes  write  access  to  TREE 

37)  parameter  for  VAL  is  always  legal 

38)  j  names  an  integer  in  the  range  1  to  n  and 

it  is  meaningful  to  assign  x  to  an  element  of  TREE 

39)  parameter  for  ER3  is  a  positive  integer 

40)  parameter  for  ELS  is  a  positive  integer 

41)  paramo i or  for  RS  is  legal  for  the  current  state  of  the  TREE 

42)  paramoh  r  for  LS  is  legal 

43)  parameter  for  DEL  always  names  the  current  value  in  NN 

44)  requires  read  access  to  the  variable  NN 
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45)  requires  write  access  to  the  variable  NN 

46)  NN  indicates  the  number  of  nodes  currently  in  TREE,  such  that 
TREE[i],  1  <  i  <  NN  is  a  node  of  the  tree 

4 7)  ERS(i)  a  ELS(i) 

48)  assumes  read/write  access  to  NOLOOP,  j>  t,  copy 

49)  f  is  called  only  after  the  immediately  preceding  call  of  f, 
whose  value  is  f’,  has  been  used  to  transform  the  tree  such  that 
A(f’)  a  the  sequence  of  values  n  div  2,  ...,  0 

is  a  sequence  of  node  value  which  satisfy  all  the  assumptions 
of  :  1 .1.4: 

50)  read  access  required  for  f 

51)  write  access  required  for  f 

52)  the  assumptions  of  :1.1.4:  o  (there  exists  a  procedure, 

siftup(j),  which  assumes  that  (ELS(j)  3  A(LS(j)))  a  (ERS(j)  3  A(RS(j))) 
and  results  in  A(j) 

53)  the  assumptions  of  :1 .4.3:  3  (there  exists  a  procedure, 

siftup(j),  which  assumes  that  (ELS(j)  3  ^ '•  S(j)))  a  (ERS(j)  3  A(RS(j))) 
and  results  in  A(j)) 

54)  (ELS(j)  3  A(LS(j)))  a  (ERS(j)  3  A(RS(j))) 

55)  the  number  of  elements  in  the  tree  equals  the  value  of  i.  Hence 
node  i  has  no  descendants 


A  good  decomposition  for  this  elaboration  is 

((y)  ((b)  ((*)  ((z)  (vw)  ((  u  ,  v  )  ((m  ((•)  ((c)  ((g) 

((  j  ,  x  ))  1.44  )  1  38  )  1.30  )  1.10  ) 

1.19  )  1.08  )  1.04  )  1.01  )  1.00  )  .71 
where  (*)  consists  of  objects  n  through  t. 

This  decomposition  localizes  the  tree  operations  to  the  objects  (*) 
from  the  previous  decomposition  and  the  uses  of  the  function  f  to  (u) 
amd  (v).  Entropy  loading  figures  are  highei  when  information  about  the 
implementation  of  the  tree  is  distributed. 
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THE  PROBLEM  OF  THE  EIGHT  QUEENS  AND  A  TELEGRAM  PROBLEM:  A  DISCUSSION 

The  developments  for  the  GCD  Computation,  the  Sequences  Problem, 
and  Heapsort  demonstrated  applications  of  the  techniques  described  in 
Chapters  II  and  III.  Similar  developments  have  been  constructed  for  the 
Eight  Queens  Problem[W]  and  a  Telegram  Problem[HEJ.  A  complete 
presentation  of  these  developments  contributes  little  to  demonstrating 
the  techniques  which  have  already  been  presented.  Instead,  the  results 
of  these  developments  are  described. 

THE  PROBLEM  OF  THE  EIGHT  QUEENS 


The  discussion  which  follows  represents  an  analysis  of  the 

development  due  to  Wirth[W],  using  the  measure  at  each  stage.  Early 

stages  possess  good  structure  but  much  information  is  shared  in  the 

final  solution.  This  problem  can  be  stated  as: 

Find  an  arrangement  of  eight  chess  queens  on  an  8  x  8  chess 
board  such  that  no  queen  is  attacked  by  any  other  b.e.  such 
ihat  each  row,  column,  and  diagonal  contains  at  most  on 
queen). 

The  first  stage  in  Wirth's  solution  is 

variable  board,  pointer,  safe; 
considerfirstcolumn; 
repeat 
begin 
trycoiumn; 
if  sate  then 
bogm 
setqueen; 

considernextcolumn 

end 

else 

regress 

end 

until  lasicoidone  or  regressoutoffirsfcol; 
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This  stage  is  accompanied  by  the  following  informal  descriptions: 


considerfirstcol.  The  problem  essentially  consists  of  inspecting 
♦he  safety  of  squares.  A  pointer  variable  designates  the  currently 

inspected  square.  The  column  in  which  this  square  lies  is  called 

the  currently  inspected  column.  This  procedure  initializes  the 
pointer  to  denote  the  first  column. 

trycolumn.  Starting  at  the  current  square  of  inspection  in  the 
considered  column,  move  down  the  column  either  until  a  safe  square 

is  found,  in  which  case  the  Boolean  variable  safe  is  set  to  true  or 

until  the  last  square  is  reached  and  is  also  unsafe,  in  which  case 
the  variable  safe  is  set  to  false. 

setqueen.  A  queen  is  positioned  onto  the  last  inspected  square. 

considernextcolumn.  Advance  to  the  next  column  and  initialize  its 
pointer  of  inspection. 

regress.  Regress  to  a  column  where  it  is  possible  to  move  the 
positioned  queen  further  down,  and  remove  the  queens  positioned  in 
the  columns  over  which  regression  takes  place.  (Note  that  we  may 
regress  over  at  most  two  columns.  Why?) 

These  informal  descriptions  do  not  provide  adequate  information  about 

the  requiresments  of  each  procedure.  For  example,  considerfirstcolumn 

can  be  interpreted  as  only  requiring  that  the  column  pointer  be 

initialized,  when  in  fact  the  program  requires  that  both  the  pointer 

desginating  the  current  square  of  inspection  be  initialized  as  well. 

This  requirement  might  be  suggested  by  the  description  of 

considernoxtcolumn  bu  not  necessarily  from  the  description  of 

considerfirstcolumn  alone.  Thus,  the  collective  descriptions  provide 

the  necessary  information  for  implementing  all  the  procedures,  but  each 

individual  description  does  not  provide  enough  information  for 


implementing  that  procedure. 
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Next,  trycolumn  and  regress  are  elaborated.  (To  this  stage,  Wirth 

has  made  no  mention  of  the  requirements  for  lastcoldone  or 

regressoutoffirstcol.) 

procedure  trycolumn; 
repeat 
begin 

advancepointer; 

testsquare 

end 

until  safe  or  lastsquare; 

procedure  regress; 
begin 

reconsiderpriorcolumn; 
if  NOT(regressoutoffirstcol)  then 
begin 

removequeen; 
if  lastsquare  then 
begin 

reconsiderpriorcolumn; 
if  NOT(regressoutoffirstcol)  then 
removequeen 
end 

end 

end; 

In  order  for  these  elaborations  to  be  correct,  certain  unstated 
assumptions  must  be  satisfied.  Two  of  tiejsi  are 

(1)  Since  the  first  operation  in  trycolumn  increments  the  pointer 
of  inspection,  its  initial  value  (set  by  considerfirstcolumn  or 
considernextcolumn  must  have  the  value  that  no  squares  are  ignored. 

(2)  reconsiderpriorcolumn  must  have  the  effect  of  extablishing  the 
context  of  the  immediately  preceding  column. 

To  this  stage,  Wirth  has  carefully  represented  the  solution  so  that 
trycolumn  and  regress  interact  little  with  the  main  program. 


Next,  Wirth  makes  the  design  decision  that  the  variable  j  will  be 
the  column  pointer  and  the  array  x[l:8]  will  be  the  square  pointers. 
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Thus  x[j]  is  the  square  pointer  for  the  j-th  column,  1  S  J  <  8.  Below 
are  the  elaborations  of  these  objects  along  with  the  assumptions  which 


they  make. 

:  i  0: 

assumptions: 


i  is  the  column  pointer,  iequires  write  access  to 
j,  assumes  the  name  of  the  first  column  is  1,  the 
array  x  is  an  array  of  pointers  such  that  x[j] 
indicates  a  square  name  in  column  j,  requires  write 
access  to  the  array  x,  the  accessed  value  of  x  must 
be  set  to  zero  since  trycolumn  will  immediately 
increment  it  by  i,  assumes  the  name  of  '.he  first  row 
is  1 

:  10:  procedure  considerfi.'stcolumn; 
begin 
j  «-  1; 
x[l]  «-  0 

end 


effects  and 
postconditions: 


:  1 1 : 


j  =  1  and  the  requirements  for  trycolumn  are 

satisfied. 


assumptions:  J  is  the  column  pointer,  requires  read  access  to  j, 

requires  write  access  to  j,  the  array  x  is  an  array 
of  pointers  such  that  x[j]  indicates  a  square  name 
in  column  j,  requires  write  access  to  the  array  x, 
the  accessed  value  of  x  must  be  set  to  zero  since 
trycolumn  will  immediately  increment  it  by  1, 

assumes  the  name  of  the  first  row  is  1,  assumes 
considernextcolumn  will  be  invoked  only  when  there 
is  a  column  named  j  +  1 

:  1 1 :  procedure  considernextcolumn; 
begin 
J  «-  j  +  i; 
x[j]  -  0; 
end; 


effects  and 

post-conditions:  j  is  incremented  by  1  and  the  requirements  for 

trycolumn  are  satisfied. 
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:12: 

assumptions: 


effects  and 
post-conditions: 

:  1 3 : 

assumptions: 


effects  and 
post-conditions: 

:14: 

assumptions: 


effects  and 
post-conditions: 


j  is  the  column  pointer,  requires  read  access  to  j, 
requires  write  access  to  j,  assumes 
reconsiderpriorcolumn  will  be  invoked  only  when 
there  is  a  column  named  j  1 

:  1 2:  procedure  reconsiderpriorcolumn; 

i  «-  j  -  1; 


the  column  pointer  has  been  set  to  the  immediately 
preceding  column 


j  s  the  column  pointer,  requires  read  access  to  j, 
the  f  ame  of  the  next  square  in  a  column  equals  the 
current  square  name  plus  1,  assumes  advancepointer 
will  only  be  called  if  there  exists  a  next"  square 
in  the  current  column,  the  array  x  is  an  array  of 
pointers  such  that  x[j]  indicates  a  square  name  in 
column  j,  requires  read  access  to  the  array  x, 
requ  res  write  access  to  the  array  x 

:  13:  procedure  advancepointer; 

x[j] «-  x[il +  i; 


x[j]  has  been  incremented  by  1  to  name  the  next 
square  in  column  j 


assumes  the  number  c t  rows  is  8,  the  array  x  is  an 
array  of  pointers  such  that  x[j]  indicates  a  square 
name  in  column  j,  requires  read  access  to  the  array 
x,  j  is  the  ccV.mn  pointer,  requires  read  access  to 

j 

:14;  Boolean  procedure  lastsquare; 
lastsquare  «-  x[j]  =  8; 


lastsquare  =  true,  if  the  last  square  in  the 
current  column  is  named  by  the  square  pointer;  false 
otherwise. 
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:15: 

j  ;s  the  column  pointer,  requires  read  access  to  ), 

assumes  the  number  of  column  is  8 

:  15:  Boolean  procedure  lastcoldone; 
lastcoldone  «-  j  >  8; 

lastcoldone  =  true  if  the  column  pointer  names  a 

column  which  is  greater  than  the  name  oi  the  last 

column. 

j  is  the  column  pointer,  requires  read  access  to  j, 

assumes  the  name  of  the  first  column  is  1 

:  16:  Boolean  procedure  regressoutoffirstcol; 
regressoutoffirstcol  *-  j  >  1; 

regressoutoffirstcol  =  true,  if  the  column  pointer 
names  a  column  which  is  less  than  the  name  of  the 

first  column 

Next,  Wirth  observes  that  by  introducing  the  Boolean  arrays  a,  b, 

and  c  with  the  meanings 

a[k]  =  true:  no  queen  is  positioned  in  row  k, 

b[k]  =  true:  no  queen  is  positioned  in  /-diagonal  k,  and 

c[k]  =  true:  no  queen  is  positioned  in  \-diagonal  k. 

testsquare,  setqueen,  and  removesquare  can  easily  be  implemented  if  the 

index  ranges  for  a,  b,  ar.d  c  are  chosen  carefully.  The  observation  that 

1,  ...  ,  8  names  the  eight  rows  suffices  for  the  range  of  k  for  a 

Further,  since  the  sums  of  the  subscripts  for  squares  on  a  board 

(board[l:8,  1:8])  in  the  /-diagonals  is  unique  for  each  diagonal  and 

identical  for  each  square  in  a  single  /-diagonal,  an  appropriate 

subscript  range  for  b  is  2,  ...  ,  16.  Similarly,  the  difference  of  the 

subscripts  (first  subscript  minus  second  subscript)  for  \-diagonals  is 


assumptions: 

effects  and 
post-conditions: 

:  1 6: 

assumptions: 

effects  and 
post-conditions: 
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unique  for 

each  \-diag0nal 

and 

identical 

for 

each  square  in 

\-diagonal. 

This  suggests  that 

the 

subscript 

range 

for  c  shoud  be 

~  ,7. 

Consequently,  the  elaborations: 


:17: 


assumptions:  j  is  the  column  pointer,  requires  read  access  to  j, 

requires  write  access  to  Boolean  variable  safe, 
assumes  the  number  of  rows  is  8,  assumes  the  name  of 
the  first  row  is  1,  the  array  x  is  an  array  of 
pointers  such  that  x[j]  indicates  a  square  name  in 
column  i,  requires  read  access  to  the  array  x,  the 
sum  oi  the  indices  in  a  single  /-diagonal  are 
identical  and  lie  in  the  range  16;  the  sum  of 
the  indices  in  a  \-diagona!  are  identical  and  lie  in 
the  range  -7,..., 7;  ,  a[k]  =  true:  no  queen  is 

positioned  in  row  k,  read  access  required  for  a, 
b[k]  •  true:  no  queen  is  positioned  in  /-diagonal  k, 
read  access  to  b  required,  c[k]  »  true,  no  queen  is 
positioned  m  \-diagonal  k,  read  access  to  c 
required 


:1 7:  procedure  testsquare; 

safe  ♦-  a[x[j]]  a  b[j  +  x[j]]  a  c[j  -  x[j]]j 


effects  and 

postconditions:  safe  -  true,  if  in  column  j,  square  x[j J  is  not 

attacked  by  any  queen  in  columns  i,  ...  ,  j-1 
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:18: 

assumptions: 


Affects  and 
post-conditions. 

:1 9: 

assumptions: 


j  is  the  column  pointer,  requires  read  access  to  j, 
assumes  the  number  of  rows  is  8,  assumes  the  name  of 
the  first  row  is  1,  the  array  x  is  an  array  of 

pointers  such  that  x[j]  indicates  a  square  name  in 

column  j,  requires  read  access  to  the  array  x,  the 
sum  of  the  indices  in  a  single  /-diagonal  are 

identical  and  lie  in  the  range  2,  ,16;  the  sum  of 

the  indices  in  a  \-diagonal  are  identical  and  lie  in 
the  range  -7,..  ,7;  ,  a[k]  *»  true:  no  queen  is 
positioned  in  row  k,  write  access  required  for  a, 

b[k]  =  true:  no  queen  is  positioned  in  /-diagonal  k, 
write  access  to  b  required,  c[k]  *  true:  no  queen  is 
positioned  in  \-diagonal  k,  write  access  to  c 

required 

:18:  prn'adure  setqueen; 

a[x[j]]  -  b[j  *•  x[j]]  «-  c[j  -  x[j]]  ^  false; 


a  queen  is  positioned  in  column  j,  square  x[, ],  and 
its  influence  in  the  appropriate  row,  and  the  two 

diagonals  is  set 

I  is  the  column  pointer,  requires  read  access  to  j, 
the  array  x  is  an  array  of  pointers  such  that  x[j] 

indicates  a  square  name  in  column  j,  assumes  the 

number  of  rows  is  8,  assumes  the  name  of  the  first 

row  is  1,  requires  read  access  to  the  array  x,  the 

sum  of  tne  indices  in  a  single  /-diagonal  are 
identical  and  lie  in  the  range  ?,  ,16;  the  sum  of 

the  indices  in  a  \-diagonal  are  identical  and  lie  in 

the  range  -7,..., 7;  ,  air.)  =  true:  no  queen  is 

positioned  in  row  k,  write  access  required  tor  a, 
b[k]  *  true:  no  queen  is  positioneo  in  /-diagonal  k, 

write  access  to  b  required,  c[k]  =  true  no  queen  is 

positioned  in  \-diagonal  k,  write  access  to  c 
required 

:19:  procedure  removequcen; 

atx t j ]]  -  b[j  ♦  x[j]]  *-  c[j  -  x[j]J  -  true; 


a  queen  is  removed  from  column  j,  as  well  as  the 
appropriate  row  and  diagonals 


effects  and 
post-conditions: 
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Below  is  the  object  assumption  table  for  these  parts. 


73456789  101 1 12I3I415I6I7I8I9702I2223242526 


*  10! 

1 

1  1 

*11* 

1 

1  1  1 

*12* 

1 

1  1 

*13* 

1 

1  1 

*  14* 

1 

1  1 

« is: 

1 

1 

*  16* 

1 

1 

*17* 

1 

1  t 

*18* 

1 

1  1 

*  It* 

1 

1  1 

1)  I  is  the  column  pointer 

2)  requites  read  access  to  j 

3)  requires  write  access  to  j 

4)  the  array  x  is  an  array  of  pointers  such  that  x[j]  indicates  • 

square  name  in  column  j 

5)  requires  read  access  to  the  array  x 

6)  requires  write  access  to  the  array  x 

7)  the  accessed  value  of  x  must  be  set  to  zero  since  trycolumn 

will  immediately  increment  it  by  1 

8)  the  name  of  the  next  square  in  a  column  equals 

the  current  square  name  plus  1 

9)  assumes  advancepomter  will  only  oe  called  if  there 

exists  a  "next"  square  in  the  current  column 

10)  assumes  t tie  number  of  rows  s  3 

11)  assumes  the  number  of  column  is  3 

12)  assumes  the  name  of  the  f  t  column  is  1 

13)  assumes  the  name  of  the  first  rc.v  is  1 

14)  assumes  considernextcolumn  will  be  invoked  only  wnen 
there  is  a  column  named  j  ♦  1 

15)  requires  write  access  to  Boolean  ,dr,abie  safe 

18)  tne  sum  of  me  indices  in  a  single  /-diagona.  are  identical 
and  lie  in  tne  range  2,...,  16;  t’e  sum  of  the  indices 
in  a  \-diagonal  are  identical  jnd  lie  in  the  range  7,..  ,7; 

17)  a[k]  «  true,  no  queen  is  positioned  in  row  k 

18)  read  access  required  for  a 

19)  write  access  required  for  a 

20)  b[k]  »  true:  no  queen  is  positioned  n  /  ,,onai  r, 

21)  read  access  to  b  required 

22)  write  acces»  to  b  required 

23)  c[kj  -  true:  no  queer  is  positioned  in  \-dtagonai  k 

24)  read  access  to  c  required 

25)  write  acce  ,s  to  c  required 

26)  assumes  reconsioerpriorcoiumn  will  be  invoiced  only  wnen 
there  is  a  column  named  j  -  1 
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In  the  absence  of  the  remaining  portions  of  the  table,  (objects  and 
assumptions  for  the  mam  program,  trycolumn,  and  regress)  it  is  still 
meaningful  to  compute  entropy  loadings  for  the  portion  displayed.  This 
is  justified  because  objects  .10:  through  :  1 9:  do  not  share  specific 
assumptions  with  the  mam  program  or  trycolumn,  or  regress. 
Consequently,  the  best  decomposition  to  this  stage,  must  involve  two 
large  parts  -  :  10:  through  :  1 9:  and  the  mam  program,  trycolumn,  regress 
-  which  ar  >  then  further  decomposed.  A  good  decomposition  for  the 
displayed  objects  is: 

((:  150  <<:  1 6:)  «:120  «:13:  ,  :14:)  «:10:  ,  :110  «:17:> 

((:  18:  ,  :  1 9:))  1.83  )  1.64  )  1.42  )  .94  )  .64  )  .64 
Better  entropy  loading  figures  can  be  found  by  noting  that  :  1 0: 

(considerfirstcol)  and  :11:  (considernextcol)  share  information  not  only 
about  j  but  also  about  x.  By  introducing  a  new  object  :20: 

(initsqofinspect),  and  modifying  :  10:  and  :11:,  a  decomposition  where 
;  1 0:  and  :  1 1 :  emerge  sooner  as  a  subset  of  a  good  decomposition  can  be 
found. 
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Below  are  the  relevant  objects: 


:  1 0: 

assumptions:  j  is  the  column  pointer,  requires  write  access  to 

j,  assumes  the  name  of  the  first  column  Is  1, 
requires  ability  to  invoke  initsqofmspoct  winch 
sets  the  square  of  inspection  to  a  value  which  is 
the  proper  initialization  for  examining  the  squares 
in  a  column  named  by  j 

:10:  procedure  considerfirstcolum 
begin 
J  «-  li 

mitsqof  inspect; 
end 

effects  and 

post-conditions:  j  *=  1  a  x[l]  =  0,  x[l]  can  be  incremented  by  1  to 

satisfy  the  requirements  for  trycolumn 

ill: 

assumptions:  j  is  the  column  pointer,  requires  read  access  to  j, 

requires  write  access  to  j,  requires  ability  to 
invoke  imtsqofinspect  which  sets  the  square  of 

inspection  to  s  value  which  is  the  proper 
initialization  for  exami  vng  the  squares  in  a  column 
named  by  j,  assumes  considernextcolumn  will  be 
invoked  only  when  there  is  a  column  named  j  +  1 

ill:  procedure  conoidernextcoiumn; 
begin 
J  *-  J  +  i; 
initsqofmspeci; 

end; 

effects  and 

post-conditions:  j  is  incremented  by  1  and  the  square  pointer  for 

the  next  column  equals  0,  to  satisfy  the 

requirements  for  trycolumn. 
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:20: 

assumptions:  j  is  the  column  pointer,  lequires  read  access  to  j, 

the  array  x  is  an  array  of  pointers  such  that  x[j] 
indicates  a  square  name  in  column  j,  requires  write 
access  to  the  array  x,  the  accessed  value  of  x  must 
be  set  to  zero  since  trycolumn  will  immediately 
increment  it  by  1,  assumes  the  name  of  the  first  row 
is  1 

:20:  procedure  initsqof  inspect  j 

*[jj  -  0; 

effects  and 

post-conditions:  x[j]  -  0  and  can  be  incremented  by  1  to  satisfy  the 

requirements  for  trycolumn. 


r  1 
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The  object/assumption  table  is  now: 

23456769  101 1 12)31415161718192021222324252627 


•*  1  Oi 

1 

1 

•‘Hi 

1 

1  1 

•  1 2* 

1 

1  1 

:  i3« 

1 

1  1  1 

1  1 

:  14: 

1 

1  1  1 

1 

S  15S 

1 

1 

1 

:  1 6* 

1 

1 

S  I7i 

1 

1  1  1 

1 

5  1  8* 

1 

1  1  1 

1 

*  1  9* 

1 

1  1  1 

1 

s  20s 

1 

1  1  1 

1 

1)  j  is  the  i  jlumn  pointer 

2)  requires  read  access  to  j 

3)  requires  write  access  to  j 

4)  the  array  x  is  an  array  of  pointers  such  that  x[j]  indicates  a 

square  name  in  column  j 

5)  requires  read  access  to  the  array  x 

6)  requires  write  access  to  the  array  x 

7)  the  accessed  value  of  x  must  be  set  to  zero  since  trycolumn 

will  immediately  increment  it  by  1 

8)  the  name  of  the  next  square  in  a  column  equals 

the  current  square  name  plus  1 

9)  assumes  advancepointer  will  only  be  called  if  there 

exists  a  "next"  square  in  the  current  column 

10)  assumes  the  number  of  rows  is  8 

11)  assumes  the  number  of  column  is  8 

12)  assumes  the  name  of  the  first  column  >s  1 

13)  assumes  the  name  of  the  first  row  is  1 

14)  assumes  considernextcolumn  will  be  invoked  only  when 
there  is  a  column  named  j  +  1 

15)  requires  write  access  to  Boolean  variable  safe 

16)  the  sum  of  the  indices  in  a  single  /-diagonal  are  identical 
and  lie  in  the  range  2,. ..,16;  the  sum  of  the  indices 

in  a  \-diagonal  are  identical  and  i'e  in  the  range  -7,. ..,7; 

17)  a[k]  «=  true:  no  queen  is  positioned  in  row  k 

18)  read  access  required  for  a 

19)  write  access  required  for  a 

20)  b[k]  -  true:  no  queen  is  positioned  in  /-diagonal  k 

21)  read  access  to  b  required 

22)  write  access  to  b  required 

23)  c[k]  *=  true:  no  queen  is  positioned  in  \-diagonal  k 

24)  read  access  to  c  required 

25)  write  access  to  c  required 

26)  assumes  reconsiderpriorcolumn  will  be  invoked  only  when 
there  is  a  column  named  j  -  1 
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27)  requires  ability  to  invoke  imtsqofinspect  which 
sets  the  square  of  inspection  to  a  value 
which  is  the  proper  initialization  for  examining 
the  squares  in  a  column  named  by  j 

The  former  decomposition,  grouping  :20:  with  :  1 0:  and  :li:  is 

«:15.)  <(:  1 6:)  «:12:)  «:13:  ,  :14s)  «:10:  ,  :11:  ,  :20:) 

((: 1 7:>  (:  1 8:  ,  :19:»  1.77  )  1.59  )  1.39  )  .86  )  .60  )  .60 
A  better  decomposition  is 

((:  1 5:)  <(:  1 6 :)  (('.12:)  <(:10:  ,  :1 1:>  <(:13:  ,  :14:)  ((:20:> 

(( :  1  7:)  (: i 8:  ,  :1 9:»  1  77  )  1.59  )  1.39  )  .66  )  .86  )  .60  )  .60 

Wr  h  concludes  the  development  by  observing  that  read  accesses  to 
x  occur  more  frequently  than  write  accesses  to  x  (This  is  apparent  from 
the  table,  so  long  as  :13:  and  :21:  are  executed  less  frequently  than 
all  the  objects  which  read  x.)  Consequently,  it  is  suggested  that  since 
array  accesses  are  usually  more  costly  than  access  to  simple  variables, 

a  new  variable,  i,  can  be  introduced  such  that  x[j]  ♦-  i;  is  always 
executed  before  j  is  incremented  and  i  *-  x(j];  is  executed  after  j  is 
decreased.  The  effect  of  introducing  this  change  and  distributing 
information  about  i,  is  to  increase  the  entropy  loadings  of  the  above 
decomposiiion. 

Lastly,  in  the  final  version  of  the  mam  program,  information  about 

i,  x,  and  j  is  freely  distributed.  This  causes  the  main  program  to 
interact  with  objects  with  which  it  did  not  interact  at  earlier  stages. 
As  a  result  entropy  loading  figures  for  the  decomposition  become 

larger,  and  in  some  cases  lead  to  saturation  where  it  did  not  occur  at 
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earlier  stages.  Further,  changes  in  the  meaning  or  use  of  x  or  ]  imply 
that  many  changes  will  have  to  be  made  throughout  the  program. 

A  TELEGRAM  PROBLEM 

Henderson  and  Snowdon[HS]  hae  proided  a  development  and  an  analysis 
of  a  program  which  was  produced  using  the  techniques  of  structured 
programming.  The  program,  however,  was  shown  to  contain  at  least  one 
"bug".  The  authors  claim  that  one  stage  in  the  development  of  more 
information  about  the  program  environment  was  distributed  than  was 
necessary.  As  a  result,  the  programmer  forgot  some  of  this  detail  at  a 
later  stage,  thus  causing  the  error.  This  observation  suggests  that 
objects  in  the  development  were  allowed  to  interact  more  than  was 
necessary.  It  also  suggests  that  by  not  explicitly  obsering 

assumptions,  programmers  construct  assumptions  which  may  or  may  not  be 
correct.  The  discussion  below  first  states  the  problem  and  then 
presents  the  deelopment  due  to  Henderson  and  Snowdon  [HE]  to  the  point 
where  the  error  occurred.  Shared  assumptions  are  emphasized. 


The  Problem 


A  program  is  required  to  process  a  stream  of  telegrams. 
This  stream  is  available  as  a  sequence  of  letters,  digits,  and 

blanks  on  some  deice  and  can  be  transferred  in  sections  of 
predetermined  size  into  a  buffer  area  where  it  is  to  be 

processed.  The  words  in  the  telegrams  are  separated  by 

sequences  of  blanks  and  each  telegram  is  delimited  by  the  word 
"TLLZ".  The  stream  is  terminated  by  the  occurrence  of  the 

empty  telegram,  that  is  a  telegram  with  no  words,  Each 
telegram  is  to  be  processed  to  determine  the  number  of 
chargeable  words  and  to  check  for  occurrences  of  overlength 
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words.  The  words  “1111"  and  "STOP"  are  not  chargeable  and 
words  of  more  than  twelve  characters  are  considered 
overlength.  The  result  of  the  processing  is  to  be  a  neat 
listing  of  the  telegrams,  each  accompanied  by  the  word  count 
and  a  message  indicating  the  occurrence  of  an  overlength  word. 

Before  proceeding,  it  should  be  noted  that  the  description  of  the 

problem  is  not  as  precise  as  it  should  be.  Aside  from  an  incomplete 

description  of  the  specific  behavior  of  commands  which  invoke  input 

operations  as  well  as  operations  which  select  single  characters  from  the 

buffer,  the  definition  of  a  "word"  is  not  precise  enough.  The  strings 

"HIT  and  "STOP"  are  not  chargeable  words,  but  from  the  program  which 

is  presented,  a  telegram  consisting  of  zero  or  more  occurrences  of 

"STOP"  followed  by  "1111"  is  considered  to  be  an  empty  telegram.  This 

interpretation  is  not  consistent  with  this  author’s  understanding  of  the 

statement  of  the  problem.  Nevertheless,  Henderson  and  Snowdon  develop  a 

solution  as  follows  (The  object  names  have  been  added  in  order  to 

clarify  the  ancestry  of  objects.) 

sl.ls  INITIALIZE  FOR  WHOLE  PROGRAM; 

:1.2;  repeat 
begin 

:  1.3:  INITIALIZE  FOR  NEW  TELEGRAM; 

:1.4:  PROCESS  TELEGRAM 
end 

until  EMPTY  TELEGRAM; 

This  program  requires  that  at  least  one  telegram  be  part  of  the 
input  and  that  an  empty  telegram  must  occur.  It  seems  questionable 
whether  :1.1:  and  : 1 .3:  should  be  stated  in  this  stage.  As  with 
version  III  of  the  GCD  computation,  such  initializations  seem  more 
natural  if  they  emerge  as  a  result  of  satisfying  the  assumptions  of 
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certain  objects. 

Next,  :1.4:  PROCESS  TELEGRAM,  is  elaborated  as 

:  1.4.1:  COUNT,  CHECK,  AND  PRINT  WORDS; 

:  1.4.2:  PRINT  WORD  COUNT  AND  CHECK  MESSAGE; 

Object  :1.4.2:  assumes  that  a  count  of  the  number  of  words  and  a  checK 
for  overlength  words  is  available.  Further,  it  is  assumed  that  :1.4.1: 
provides  this  information.  Hence,  in  the  absence  of  an  explicit  attempt 
to  hide  the  mechanisms  which  provide  this  information  :1A1:  and 
:1.4.2:  must  share  several  a:-umptions.  All  assumptions  about  telegram 
syntax  and  information  about  what  is  to  be  recorded  for  each  telegram  is 
contained  in  :1.4.1:.  No  assumptions  about  the  explicit  manner  of 
inputting  text  have  yet  been  made. 

The  elaboration  of  :1.4.1:  is 

:1. 4.1.1:  repeat 
begin 

:  1.4. 1.2:  EXTRACT  WORD; 
sl.4.1.3:  if  WORD  IS  CHARGEABLE  then 
:1.4.1.4s  COUNT  WORD; 

:  1.4. 1.5:  if  WORD  IS  TOO  LONG  then 
:1.4.1.6:  SET  CHECK  FLAG; 

:  1 .4. 1 .7:  PRINT  WORD; 
end 

until  WORD  IS  "ZZZZ"; 

:1. 4.1.2:  requires  information  about  what  const  tutes  a  word,  i.e.  the 
next  sequence  of  non-blank  characters.  :  1.4. 1 .3:  requires  information 
about  which  words  are  chargeable,  i.e.  words  which  are  not  STOP  or 
"ZZZZ".  :1.4.1.5:  requires  the  information  about  what  constitutes  an 
overlength  word.  Objects  :1.4.1.4:  and  :1.4.1.6:  require  variables  that 
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reflect  the  state  of  the  number  of  words  in  the  current  telegram  and 
whether  any  overlength  words  have  occurred  in  this  telegram.  At  this 
point,  the  values  of  these  variables  are  observed  to  require  some  kind 
of  initialization.  Thus,  :1.3s,  :1.4.1.4:  and  :  1 .4. 1 .6:  share 

assumptions. 

Object  :  1.4. 1.2:,  EXTRACT  WORD,  is  elaborated  as 

:  1.4. 1.2.1:  SET  WORD  EMPTY  INITIALLY; 

:1.4.1.2.2:  ADJUST  INPUT; 

:  1.4. 1.2.3:  repe^i 

:1  4.1.2.4:  EXTRACT  LETTER 

until  LETTER  IS  SPACE; 

This  elaboration  is  really  the  source  of  the  error  which  occurs  in 
the  final  program.  Until  this  stage,  all  assumptions  have  been 

concerned  with  the  properties  of  telegrams,  but  :1.4.1.2.2:,  ADJUST 
INPUT,  necessarily  introduces  assumptions  about  the  way  input  is 
performed  or  at  least  about  how  the  buffer  is  managed.  Similarly, 
:  1 . 4.1. 2.4:,  EXTRACT  LETTER,  makes  some  of  these  assumptions. 
:1. 4.1. 2.4:.  This  implies  that  these  objects  rhare  assumptions  which 

are  not  directly  related  to  the  task  of  extracting  the  next  word  from 
the  telegram.  The  descriptions  a-e  also  not  precise.  The  authors 
comment  that  the  condition 

first  letter  of  input  4  space 

must  hold  prior  to  the  execution  of  :1. 4.1. 2.3:.  Ths  condition  is  not 
necessarily  suggested  as  the  effect  of  the  phrase,  ADJUST  INPUT. 
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A  clearer  elaboration  might  be 


repeat 

EXTRACT  LETTER 
until  LETTER  IS  NOT  A  SPACE; 

SET  WORD  TO  EMPTY; 

repeat 

begin 

CONCATENATE  LETTER  TO  THE  RIGHT  END  OF  WORD; 

EXTRACT  LETTER 

end 

until  LETTER  IS  A  SPACE; 

(Implicit  in  both  elaborations  is  the  assumption  that  a  space  always 
follows  a  woid,  even  if  a  letter  is  the  last  character  of  the  entire 
input  file.  The  authors  solve  this  difficulty  by  concatenating  a  space 
to  the  end  of  each  input  record.)  This  second  elaboration  local  zes  all 
assumptions  about  handling  input  to  EXTRACT  LETTER  and  its  elaborations. 
As  a  result,  entropy  loading  figures  for  decompositions  of  the  program 
involving  this  second  elaboration  are  generally  lower  than  for  the 


Original  program. 


CHAPTER  V 


r 
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Chapter  IV  presented  examples  of  how  entropy  loading  calculaiions 
could  be  used  as  guides  to  help  control  program  structure.  (Appendix  I 
applies  these  techniques  to  a  larger  program.)  This  chapter  first 
summarizes  the  major  results  of  each  example.  Next,  the  potential 

advantages  of  using  the  methodology  and  the  measure  are  stated.  Using 
the  measure  in  a  practical  situation,  however,  poses  certain 

difficulties.  These  are  listed  and  form  the  basis  for  several 

suggestions  for  future  research. 

REVIEW  OF  RESULTS  DEMONSTRATED  BY  THE  EXAMPLES 

This  thesis  has  investigated  the  question  of  whether  a  particular 

methodology  describes  program  structure  as  defined  in  Chapter  II.  The 
methodology  under  investigation  uses  a  mathematical  calculation,  called 
entropy  loading,  in  two  ways.  First,  given  a  development  of  a  program 
where  the  assumptions  have  been  preserved  at  each  stage,  entropy  loading 
figures  can  compare  different  arrangements  of  objects  in  an  attempt  to 
discover  which  groupings  of  objects  interact  least.  Such  decompositions 
might  suggest  ways  for  constructing  a  set  of  modules  whose  combined 
effects  solve  the  original  problem.  Second,  if  a  particular 
decomposition  is  suggested  at  early  stages  in  a  development,  entropy 
loading  figures  can  be  used  to  observe  whether  the  development  at  later 
stages  still  possesses  similar  structural  properties.  If  good  structure 

_ _ 
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is  not  preserved,  the  object/assumption  table  (in  which  the  assumptions 
are  preserved)  might  suggest  ways  of  localizing  certain  assumptions  to 
existing  or  new  objects. 

In  Chapter  IV,  three  versions  of  a  program  that  computes  the 
greatest  common  divisor  are  analyzed.  The  map  for  version  I  and  the 
trees  corresponding  to  two  decompositions  of  the  final  program  appear 

below. 


A  GCD  COMPUTATION 


sis  (pg.  31) 

:1.1:132)  :1.2:  (32) 


:  1.2. 1 :  (34) 
(x  «-  a) 


:11.1.1s  (36)  :1. 1.1.2:  (36) 

(while  a  ji  b  do 

sl.1.1.2:;) 


:(.l.  1.2.1:  (37) 


\ 

\ 


:i.l.  1.2.1. 1:  (39)  :1.1.1.2.1.2:  (39)  :1.1.1.2.1.3:  (39) 
(  if  a  >  b  then 
:1. 1.1. 2.1. 2: 

•lie 

:1, 1.1. 2. 1.3:  j) 


•.1.1.1.2.1.21:  (41) 
\S  *•  a  -  Z) 


:1  1 . 1.2. 1.3.1:  (41) 

S  O  "  a ) 
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(A) 

/V  .  500  500 

:1.2.1:\.950  or  *1.2.1:  .950 

:1.1.1.2.L2.l\  .673  :1.1.1A1A1s>\.673 

:1. 1.1. 2. 1.3.1:  (:1. 1.1.1:,  -.1.1.1. 2.1.2. 1:  (:1.1  1  •  1 

:1.1. 1.2.1. 1:) 

-.1.1  1.2. 1.1:) 

(B) 

.  .500 

:  1.2. 1 :  1.05 

01.1.1  1-.,  :1. 1.1. 2. 1.1:)  (:1. 1.1. 2.1. 2.1:, 

:1. 1.1.2  1.3.1) 

This  analysis  corresponds  to  an  attempt  to  find  the  best  way  of 
decomposing  this  fixed  program.  The  measure  indicated  that  the  best 
decomposition  of  the  program  is  decomposition  (A).  The  part  which 
interacts  least  with  the  rest  of  the  program  is  :1.2.1:  that  assigns  the 

value  of  a  to  x.  Objects  :1.1.1.2.1.2.1:  and  :1.1.1.2.1.3.1:  assign 

values  to  a  and  b  and  also  require  more  information  than  :1.2.1s  but 
less  information  than  :1. 1.1.1:  and  :1. 1.1.2. 1.1:.  These  last  objects 

determine  the  flow  of  control  within  the  program.  This  result  is 

consistent  with  the  definition  of  structure  and  our  intuitive  ideas.  In 
this  example,  the  assumptions  associated  with  the  control  mechanisms 

include  information  about  what  is  being  controlled.  No  attempt  was  made 
to  hide  that  information.  However,  the  objects  being  controlled  were 
constructed  without  making  assumptions  about  mechanisms  that  control 
them.  Decomposition  (B)  is  slightly  worse  because  the  statements  (a  <-  a 

read  and  write  access  to  both  a  and  b.  Hence, 


-  b,  b  ♦-  b  -  a)  require 
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more  information  is  localized  to  a  single  subset  than  in  (A)  where  write 
access  to  a  and  b  are  separated. 

Version  II  is  similar  to  version  I  except  that  the  construction 
if  a  >  b  then  a  *-  a  -  b  else  b  ♦-  b  -  a; 

is  replaced  by 

while  a  >  b  do  a  i-  a  ■  b; 
while  b>adob*-b-a; 

Here,  the  best  decomposition, 

«•)  «g  ,  h)  (b)  «c  ,  •))  1.01  )  1.01  )  .451 

indicates  that  (a)  [x  «-  a]  interacts  least  with  the  rest  of  the  program 

and  that  of  the  remaining  portion,  (g  ,  h)  (a  *-  a  -  b,  b  «-  b  -  a) 

interacts  least  with  the  control  mechanisms  b  (while  a  /  b  do)  and  (c  , 

e)  (while  a  >  b  do,  while  b  >  a  do). 

Version  III  illustrates  a  development  similar  to  version  II,  but  in 
addition  to  computing  the  greatest  common  divisor  of  a  and  b,  their 
least  common  multiple  is  also  computed.  Here,  the  decomposition 
((a)  ((b)  ((c)  «k  ,  I)  (g  ,  i»  1.55  )  1.75  )  1.75  )  1.28 
indicates  that  (a)  [  x  ♦-  a;  y  ♦-  c  +  d;  ]  interacts  least  with  the  rest 

of  the  program,  but  that  the  control  mechanisms  for  the  inner  loops  as 
well  as  the  statements  which  they  control  interact  most.  Object  b  (c  «- 

0;  d  «-  a)  initializes  c  and  d,  but  really  shares  little  information  with 

the  rest  of  the  program.  Simhrly,  object  c  (  while  a  H  b  do  ) 
controls  the  inner  loops  but  interacts  little  with  the  mechanisms  which 
decrease  a  and  b.  Note  that  the  entropy  loading  figures  for  this 
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decomposition  are  larger  than  the  corresponding  figures  for  version  II. 
This  occurs  because  the  objects  in  version  III  make  assumptions  that  are 
shared  in  more  complicated  ways  than  the  objects  in  version  II. 

The  development  of  the  sequences  problem  shows  that  distributed 
information  about  a  scheme  for  representing  data  can  lead  to 

unnecessarily  complicated  structure.  This  example  produces  a  list  of 
lexicographically  ordered  sequences  such  that  each  sequence  contains 
only  l’s,  2’s  and  3’s,  but  no  adjacent  identical  subsequences  The  list 

is  terminated  by  the  first  such  sequence  containing  100  digits.  The 
development  to  the  stage  where  information  ab-tu'  the  representation  of  a 
sequence  in  terms  of  an  array  resulted  in  the  decomposition 
((b)  ((d)  ((a)  ((e)  ((h)  ((f)  (k  ,  j» 

1.21  )  1.21  )  1.91  )  1.38  )  1.21  )  1.21 

Entropy  loadings  for  this  decomposition  are  all  greater  than  or  equal  to 
entropy  loadings  for  the  same  Decomposition  where  implementation- 
information  was  not  distributed.  This  suggests  that  the  implementation 
information  be  localized  to  one  or  several  objects.  in  this  case, 
additional  objects  were  introduced.  This  resulted  in  entropy  loadings 
that  were  smaller  and  very  close  to  the  entropy  loadings  for  the 
decomposition  prior  to  elaborating  the  implementation.  Thus,  the 
measure  provided  indications  that  motivated  a  rearrangement  of  the 
program  so  that  the  reasonably  good  structure  of  the  early  stages  was 


preserved  in  the  final  program. 
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The  example  that  develops  a  sorting  program  based  on  the  algorithm 
HEAPSORT  attempts  to  present  a  program  in  terms  of  the  model  that 
probably  motivated  the  algorithm:  a  binary  tree  representing  the  data  to 
be  sorted.  One  reason  for  attempting  this  exercise  was  to  first 
describe  the  algorithm  without  presenting  all  the  details  of  its 

implementation.  Then  a  particular  representation  for  the  binary  tree  - 

as  a  linear  array  -  is  introduced.  As  a  consequence  of  this  decision, 
information  about  the  representation  can  be  localized  to  certain  objects 
without  adversely  affecting  the  decompositions  suggested  at  earlier 
stages.  Although  applications  of  the  measure  eventually  suggested  a 
decomposition  that  localized  almost  all  assumptions  about  the 
representation  to  one  object  (:3:,  the  siftup  procedure),  earlier 
decompositions  had  to  be  discarded.  One  reason  for  this  occurrence  is 
that  the  small  number  of  objects  make  many  assumptions.  As  a  result, 
saturation  occurred  at  several  early  stages.  Further,  since  nor  e  of  the 
assumptions  were  weighted  with  "probability  of  change  figures,  some  of 
the  decompositions  seemed  to  be  counter  to  the  author’s  view  of  what  a 
good  decomposition  should  be.  For  example,  the  two  objects  invoking  the 
procedure  siftup  do  not  form  a  single  subset  in  the  decomposition  that 
is  presented  -  probably  because  one  call  of  siftup  uses  i  os  its 
parameter,  and  i  is  used  throughout  the  program,  where  the  other  call 
uses  root  as  its  parameter,  and  root  is  used  in  few  places. 

The  example  that  presents  the  Eight  Queens  Problem  shows  several 
improvements  in  a  program  that  already  possesses  fairiy  good  structure. 


ON  ASPECTS  OF  USING  THE  MEASURE:  SUMMARY,  EVALUATION,  CONCLUSIONS  190 
REVIEW  OF  RESULTS  DEMONSTRATED  BY  THF  EXAMPLES 


First,  the  procedures  considerfirstcolumn  and  considernextcolumn  not 
only  share  information  about  how  the  columns  of  the  chess  board  are 
arranged  and  named,  but  also  about  certain  requirements  of  another 
object,  trycolumn.  By  creating  a  new  object,  initsqofinspect,  a 

decomposition  that  was  already  rather  good  was  slightly  improved.  In 
Wirth’s  original  program,  the  objects  considernextcolumn  and 

considerfirstcolumn  not  only  share  information  about  the  names  and 
ordering  of  columns  of  squares  on  a  chess  board,  but  also  about  how  the 
squares  are  represented  and  about  some  of  the  assumptions  made  by 
trycolumn.  initsqofinspect  contains  these  assumptions  about  trycolumn 

and  thus  helps  to  improve  the  structure  of  the  program.  The  final 
version  of  Wirth’s  program  distributed  information  that  was  not  shared 
at  earlier  stages,  thus  making  these  decompositions  worse  than  they  need 
be.  This  corresponds  to  the  similar  situation  in  the  development  of  the 
sequences  problem.  Saturation  was  also  apparent  at  early  stages. 

The  discussion  of  the  telegram  problem  was  presented  in  order  to 
emphasize  the  importance  of  precisely  stated  assumptions.  Henderson  and 
Snowdon[HE]  have  stated  that  informal  Englisn  comments  are  not 
sufficient  to  suggest  the  assumptions  which  objects  make  or  the  affects 
thev  are  intended  to  produce.  For  example,  the  condition 

first  letter  of  input  /  space 

is  not  necessarily  suggested  by  the  phrase  "ADJUST  INPUT".  Such 
imprecision  is  mentioned  as  a  potential  source  for  errors  in  a  program. 
The  example  also  cites  a  portion  of  the  development  where  apparently  too 
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much  detail  was  introduced,  The  elaboration  of  :1A1.2:,  EXTRACT  WORD, 
introduces  an  object  that  caters  to  the  requirements  of  the  input 
device.  This  implies  that  the  elaboration  of  ADJUST  INPUT  and  EXTRACT 
LETTER  will  probably  share  assumptions  about  the  nature  of  the  input 
device.  An  alternative  is  presented  that  localizes  all  this  information 
to  EXTRACT  LETTER.  The  entropy  loading  figures,  though  not  displayed, 
indicate  that  this  new  version  possesses  better  structure. 


Appendix  I  applies  the  measure  to  a  development  of  a  Markov 
Algorithm  interpreter.  Although  the  analysis  of  the  example  is 
lengthy,  several  results  can  be  stated  here: 


(1)  The  structure  imposed  at  the  initial  stages,  i.e. 
alphabet  and  generic  input,  algorithm  input,  error  handling 
during  input,  algorithm  execution,  and  error  handling  during 
execution,  could  be  maintained  in  the  final  version  if 
additional  objects  were  introduced  to  provide  access  to  the 
results  of  these  additional  objects.  For  example,  objects 
which  created  internal  representations  of  rules  were 
introduced  along  with  accessors  to  this  information.  These 
emerged  together  in  a  subset  after  those  subsets  that 
constituted  the  structure  at  the  initial  stages. 

(2)  Due  to  the  large  number  of  objects  and  assumptions, 

several  clerical  aids  had  to  be  used  extensively.  These  aids, 
and  suggestions  for  extending  them,  are  described  in  a  later 
section. 

(3)  As  in  the  development  of  HEAPSORT,  several  good 

decompositions  found  at  intermediate  stages  had  to  be 
discarded.  This  was  necessary  because  later  elaborations 

resulted  in  objects  that  shared  much  information  with  objects 
that  existed  prior  to  the  elaboration.  For  example,  the  rule 

input  portion  was  elaborated  after  the  portion  that  handled 
alphabets  and  generic  input.  The  earlier  decomposition  had  to 
be  modified.  A  similar  situation  occurred  when  the  algorithm 
execution  part  was  elaborated. 
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Appendix  II  discussed  a  paper  on  Compiler  Structure[M  KJ.  This 
paper  asserted  that  special  care  should  be  taken  to  describe  the 
languages  at  the  interfaces  between  vertically  fragmented  modules  in  a 
compiler.  However,  because  of  the  results  from  the  Markov  Algorithm 
Interpreter,  it  was  concluded  that  as  much  information  about  these 
languages  should  be  hidden.  Instead,  only  creators  and  accessors  of  the 
needed  information  should  be  provided. 

ADVANTAGES  OF  USING  THE  MEASURE 

This  thesis  has  applied  a  measurement  function  based  on  entropy 
loadings  to  evaluate  decompositions  of  programs.  These  applications 
produced  results  that  usually  corresponded  to  intuitive  ideas  about 
structure  in  programs.  Unfortunately,  there  are  practical  problems 
about  deciding  the  relative  importance  of  assumptions  as  we'l  as 
problems  about  determining  and  manipulating  assumptions  and  tables. 
These  problems  impede  the  effective  use  of  the  measure  and  methodology. 
Details  of  the  advantages  and  disadvantages  of  using  the  measure  are 
discussed  in  this  and  the  next  section. 

In  order  to  apply  the  measure,  the  methodology  requires  that  the 
objects  and  assumptions  be  explicitly  stated  -  not  only  nt  early  stages 
in  the  design  process,  but  also  in  the  final  program.  Ideally  each 
object  is  accompanied  by  the  assumptions  it  makes  so  that  the  object  is 
understandable  without  requiring  additional  context.  This  feature  is 
typically  no  present  in  the  more  traditional  approaches  to  design  and 
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programming.  Further,  the  assumptions  made  by  objects  are  summarized  in 
object/assumption  tables.  This  summary  makes  it  possible  to  observe  the 
assumptions  that  are  shared  among  objects  without  needing  to  deduce  them 
from  the  program  text.  This  is  especially  helpful  whenever  entropy 

loading  figures  become  larger  than  anticipated.  Under  these 
circumstances,  other  decompositions  are  suggested  more  readily  than  in 
situations  where  object/assumption  tables  are  not  available. 

The  measure  provides  a  way  of  comparing  different  decompositions  of 
a  program  at  each  stage  in  its  development.  These  comparisn.is  help  to 
substantiate  decisions  to  reject  or  retain  a  decomposition.  As  a 

result,  there  are  at  least  quantitative  grounds  for  arguing  for  or 
against  a  decomposition  rather  than  primarily  intuitive  ones.  The 

sequences  example  emphasizes  this  point. 

The  act  of  "hiding"  information  can  be  explicitly  represented  by 

the  methodology.  Hidden  information  is  preserved  in  object/assumption 
tables. 

Decompositions  resulting  from  applications  of  the  measure  can 
possess  some  of  the  properties  advocated  by  Parnas[PAl,PA2,PA3].  In 
particular,  subsets  that  share  few  assumptions  can  suggest  modules 

similar  to  those  described  by  Parnas.  For  example,  the  analysis  of  the 
Markov  Algorithm  interpreter  suggests  that  objects  which  create  and 
manipulate  Markov  rules  should  appear  in  a  single  subset  even  though 

they  are  invoked  from  portions  which  interact  little.  Further,  the 
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descriptions  of  objects  required  by  the  methodology  can  help  to  suggest 
specifications  similar  to  those  proposed  by  Parnas.  One  characteristic 
o'  these  specifications  is  that  each  describes  the  intended  behavior  of 
a  function  without  stating  an  algorithm  that  implements  it.  Many  of 
these  behavioral  descriptions  occur  among  the  assumptions  of  objects  at 
early  stages  in  the  development  of  a  program.  These  can  be  used  to  help 
generate  Parnas-type  specifications.  As  an  example,  below  is  a 

spec'fication  for  a  function  which  might  be  used  by  the  first  version  of 
the  GCD  computation 

function  PGCD(a.b)  -  a  and  b  are  integer  parameters. 

effects:  ERC1  if  a  S  0 

ERC2  if  b  <  0 

gcd(a,b)  =  gcd(a’,b’)  a  ((a’  t  b’)  3 

(a  <  a’  or  b  <  b’)) 

This  specification  was  found  by  using  tests  for  the  assumptions  to 
suggest  error  calls  and  describing  the  effects  of  objects  as  part  of  the 
effects  of  the  function.  An  important  property  of  the  error  calls  is 
that  each  represents  some  testable  condition.  Some  assumptions  may  not 
represent  such  conditions.  Since  predicates  relating  to  the  correct 
behavior  of  objects  appear  as  assumptions,  the  objects  can  be 
constructed  with  these  assumptions  in  mind.  Specifically,  a 
designer/programmer  will  be,  perhaps,  more  conscious  of  the  explicit 
demands  his  objects  must  meet.  The  error  that  occurred  in  the  Telegram 
Problem  might  not  have  occurred  had  these  assumptions  been  explicit. 
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Again  because  assumptions  are  presented  explicitly,  changes  in  a 
program  that  require  violations  of  some  assumptions  can  be  made  more 
easily  than  under  circumstances  where  assumptions  are  not  stated.  A 
programmer  need  only  examine  the  object/assumption  table  to  determine 
which  assumptions  are  violated.  As  a  result,  the  affected  objects  can 
be  changed.  The  overhead  of  deducing  the  effects  of  changes  from 
program  text  and  other  traditional  aids  is  eliminated. 

DIFFICULTIES  OF  USING  THE  MEASURE 

It  should  be  apparent  that  entropy  loading  calculations  can  be 
computed  easily  once  the  assumptions  made  by  objects  have  been  displayed 
in  an  object/assumption  table.  Finding  these  assumptions,  however,  is 
often  a  painstaking  process.  This  process  is  made  even  more  difficult 
by  what  seems  to  be  a  natural  tendency  to  postpone  the  task  of  stating 
assumptions.  As  a  result,  the  task  becomes  more  difficult  because  the 
assumptions  made  by  earlier  stages  must  be  deduced  from  a  conirxt  that 
is  different  from  the  context  that  motivated  those  stages.  Most  often 
this  exercise  of  strung  assumptions  and  using  the  measure  to  check 
various  decompositions  leads  to  results  that  might  already  have  been 
expected.  The  interesting  cases,  of  course,  are  those  where  this 
exercise  led  to  unexpected  results  or  actually  uncovered  an  error.  The 
decompositions  found  during  the  middle  middle  stages  in  the  development 
of  HEAPSORT  as  well  as  during  the  middle  stages  of  the  Markov  Algorithm 
Interpreter  did  not  possess  good  structure  at  later  stages.  This 
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occurred  because  objects  that  were  elaborated  after  those  stages  shared 
many  assumptions  with  earlier  elaborations  of  objects.  Lastly, 
instances  where  several  designers  are  elaborating  different  objects  or 
where  objects  are  elaborated  without  a  knowledge  of  other  objects  often 
lead  to  incompatible  representations  of  similar  assumptions. 
Consequently,  interactions  may  not  be  represented  properly  in 
object/assumption  tables. 

Of  the  different  kinds  of  assumptions,  the  most  difficult  to  state 


^re  weakest 

pre-conditions 

for 

objects. 

This  difficulty  is  not 

surprising  in 

the  light  of 

all 

the  practical  difficulties  associated 

with  program 

verification. 

Once 

found, 

however,  these  assumptions 

provide  vital 

information 

about 

the 

reouirements  of  objects. 

Assumptions  about  program  environment  are  more  easily  recognized,  but 
can  frequently  be  overlooked.  For  example,  a  designer  working  on  an 
elaboration  of  a  single  object  might  make  an  assumption  so  frequently 
that  he  omits  it  from  the  object/assumption  table.  This  could  lead  to 
an  eventual  decomposition  where  this  unstated  assumption  is  violated. 
Probably  the  easiest  assumptions  to  state  are  the  mathematical  theorems 
relevant  to  the  problem  a  id  the  assumptions  about  data.  The  theorems 
are  often  related  to  the  weakest  pre-conditions.  The  assumptions  about 
data  refer  to  those  items  that  are  explicitly  stated  in  many  informal 
descriptions  of  objects  and  relate  to  items  that  are  analogous  to  what 
will  be  manipulated  in  the  language  which  implements  the  program. 
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In  addition  to  the  difficulties  in  stating  assumptions,  there  are 

difficulties  involved  in  just  manipulating  tab.es  and  selecting 

decompositions  for  which  to  compute  entropy  loadings.  Object/assumption 
tables  can  become  large  even  for  small  numbers  of  objects. 

4 

In  chapter  III,  certain  kinds  of  object/assumption  tables  were 
cited  for  which  all  decompositions  had  identical  entropy  loadings. 

Hence,  the  measure  was  unable  to  distinguish  among  them.  This  was 

called  saturation  in  object/assumption  tables.  Saturation  occurs  most 
frequently  whenever  a  small  number  of  objects  share  many  assumptions. 
The  developments  of  HEAPSORT  and  the  Markov  Algorithm  Interpreter 

displayed  instances  of  saturation. 

In  all  but  the  simplest  situations,  it  is  difficult  to  assign 

"probability  of  change"  figures  or  "relative  importance"  to  assumptions. 
Consequently,  all  the  assumptions  in  the  examples  were  treated  as  thojgh 
they  were  of  equal  importance. 

Without  the  help  of  mechanical  aids,  the  process  of  construing 

programs  using  the  methodology  ar,:i  the  measure  is  tedious  and  time 
consuming.  An  experienced  programmer  might  De  able  to  construct 
programs  having  good  structure  in  far  less  time. 

AIDS  TO  APPLYING  THE  MEASURE  AND  SUGGESTIONS  FOR  FUTURE  WORK 

As  aids  to  help  solve  some  of  the  difficulties  stated  in  the  last 
section,  several  programs  have  been  constructed.  These  programs  perform 
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the  following  tasks: 

(1)  input  and  maintain  files  of  assumptions 

(2)  input  and  maintain  abbreviated  descriptions  of  objects  and 
their  assumptions. 

(3)  produce  object/assumption  tables  given  files  generated  by  (1) 

and  (2). 

(4)  produce  listings  of  objects  given  files  generated  by  (1)  and 

(2). 

(5)  compute  entropy  loading  calculations,  RLB’s,  and  RUB’s  given 

object/assumption  tables  produced  by  (3). 

These  programs  have  been  used  to  help  produce  all  the  examples  in 

Chapter  IV  ano  in  the  appendices.  Each  is  intended  to  help  solve  some 

clerical  or  tedious  aspect  of  using  the  measure.  As  the  examples 

indicate,  a  great  deal  of  text  might  need  to  be  manipulated  for  even 

small  programs.  These  programs  have  been  written  to  execute  in  an 

interactive  environment.  This  has  proved  to  be  helpful  when  entropy 

loading  calculations  wore  performed.  Values  for  RLB,  RUB  and  the  actual 

entropy  loadings  could  be  compared  quickly  in  this  kind  of  environment. 

However,  m  order  to  use  the  measure  in  more  realistic  and 

practical  situations,  the  following  topics  suggest  areas  for  future 
research: 


(1)  Since  assumptions  about  the  meaning  and  interpretation  of 
variables  occur  so  frequently,  and  since  explicitly  transcribing 
them  -  or  their  names  -  to  identified  objects  is  tedious  and  time 
consuming,  mechanical  aids  should  he  available  that  allow  a 
programmer  to  state  these  assumptions  only  once  -  perhaps  as  part 
of  some  declaration.  Then,  the  program  support  should 
automatically  associate  the  appropriate  given  specific  constructs 
and  specific  post-conditions. 


ON  ASPECTS  OF  USING  THE  MEASURE:  SUMMARY,  EVALUATION,  CONCLUSIONS  199 
AIDS  TO  APPLYING  THE  MEASURE  AND  SUGGESTIONS  FOR  FUTURE  WORK 


(2)  Assumptions  about  control  and  frequency  of  use  of  objects 

should  be  expressable  precisely. 

(3)  Because  the  process  of  making  assumptions  can  require  careful 

and  time  consuming  thought,  as  many  assumptions  as  possible  should 

be  generated  mechanically. 

(4)  Because  of  the  substantial  difficulties  associated  with 
applying  the  measure,  additional  measures  of  structure  should  be 
sought. 

CONCLUSIONS 

The  purpose  of  this  thesis  has  been  to  help  clarify  the  notion  of 
structure  in  programs  and  to  evaluate  the  behavior  of  a  particular 

measure  of  structure.  The  most  difficult  aspects  of  applying  the 

measure  relate  to  the  process  of  making  assumptions  explicit.  Many  of 
these  difficu'ties  can  be  obviated  by  mechanical  aids  that  can  be  part 
of  the  environment  in  which  the  measure  is  to  be  used.  The  information 

about  programs  provided  by  the  measure  makes  possible  comparisons  of 

different  decompositions  of  a  program.  This  is  demonstrated  in  Chapter 
IV  and  the  appendices.  If  interactions  are  more  extensive  than  is 
desirable,  the  object/assumption  table  tells  exactly  which  assumptions 
are  shared  and  can  suggest  that  certain  assumptions  be  localized  to  new 
or  existing  objects.  Parnas-type  specifications  seem  to  be  deducible  in 
a  direct  way  from  the  assumptions  made  by  objects  and  their  effects. 

This  thesis  has  attempted  to  demonstrate,  use,  and  evaluate  a 
definition  and  measure  of  program  structure.  It  represents  an  attempt 
to  extend  the  notion  of  structure  from  its  role  as  an  aesthetic  tool  to 

a  useful  and  measurable  aid  for  finding  good  programs.  Despite  several 
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significant  shortcomings,  the  measure  provides  a  quantitative  valuation 
of  a  heretofor  vague  concept. 


BIBLIOGRAPHY 


[ALJ  Alexander,  C.  Notes  on  the  Synthesis  of  Form, 

Harvard  University  Press,  1964 

[BA]  Baker,  F.T.  Chief  programmer  team  management  of  production 
programming.  IBM  Systems  Journal  v.ll.no.l, 

January,  1972,  pp.  56-73 

[COO]  Cook,  S.A.  The  complexity  of  theorem  proving  procedures. 

Proc  of  the  Third  Annual  Symposium  on  Theory  of  Computing, 
ACM,  May,  1971,  pp.  151-157 

[DJI]  Dijkstra,  E  W,  Notes  on  structured  programming, 

Structured  Programming,  Academic  Press,  1972 

[DJ2]  Dijkstra,  E.W.  A  constructive  approach  to  the  problem 
of  program  correctness.  BIT  8  (1968)  pp. 174-186 

[DJ3]  Dijkstra,  E.  W.  EWD316:  A  Short  Introduction  to  the  Art  of 
Programming,  Eindhoven,  The  Netherlands,  1971 

[DJ4]  Dijkstra,  E.W.  The  structure  of  the  T.H.E.  multiprogramming 
system.  CACM  11  (1968)  pp.  341-346 

[DJ5]  Dijkstra,  E.W.  On  the  axiomatic  definition  of  semantics, 
(unpublished  ms.) 

[DJ6]  Dijkstra,  E.W.  Go  to  statement  considered  harmful. 

CACM  11,  3  (March  1968) 

[H]  Heymanns,  F.  A  Markov  Algorithm  Interpreter, 

(unpublished  program) 

[HE]  Henderson,  P.  and  R.  Snowdon,  An  experiment  in  structured 
programming.  BIT  12  (1972),  pp.  38-53 

[HOI]  Hoare,  C.A.R.  An  axiomatic  basis  for  computer 

programming.  CACM  12  (1969)  pp.  576-580 

[H02]  Hoare,  C.A.R.  Proof  of  a  program:  FIND 
CACM  14  (January  1971)  pp.39-45 

[H03]  Hoare,  C.A.R.  Notes  on  data  structuring.  Structured 
Programming,  Academic  Press,  1972 


BIBLIOGRAPHY 


202 


[  »A]  Karp,  R.M.  Reducibility  among  combinatorial  problems. 

Complexity  of  Computer  Computations,  R.E.  Miller  and 
J.W  Thatcher,  eds.,  Plenum  Press,  1972 

[Klj  King,  J.C.  A  Program  Verifier,  Ph.  D,  Thesis, 

Dept,  of  Computer  Science, 

Carnegie  Mellon  University,  1969 

[KN1]  Knuth.D.E.  Fundamental  Algorithms,  Addison-Wesley, 

1968,  pp.  187-189 

[KN2]  Knuth,  D.E,  Sorting  «nd  Searching,  Addison-Wesley, 

1972,  pp.  145-  47 

[LE]  Leavenwc.  in,  B.  Review  of  paper  by  P  Naur  ["Programming 
by  action  clusters."  BIT  9,  3  (1969),  250-258]. 

Computing  Reviews  11,  7  (July  1970),  Rev.  19,420 

[LO]  London,  R.L.  Certification  of  algorithm  245  Treesort3. 

proof  of  algorithms  -  a  new  kind  of  certification. 

CACM  13  (1970)  pp.371-373 

[Mil]  Mills,  HD.  Top  down  programming  in  large  systems. 

Debugging  Techniques  in  Large  Systems,  R.  Rustin,  ed., 
Prentice  Hail,  1970,  pp  41-55 

[M12]  Mills,  H.D.  Structured  Programming, 

IBM:  Federal  Systems  Division,  Gaithersburg,  1970 

[MK]  McKeeman,  W.M.,  Horning,  J.,  and  Wortman,  D.B.  A  Compiler 
Generator,  Prentice-Hall,  1970 

[MK1]  McKeeman,  W.M.  Compiler  Structure,  Technical  Report  CSRG-23, 
University  of  Toronto,  January,  1973 

[NA2]  Naur,  P  Programming  by  action  clusters.  BIT  9 
(1969)  pp. 250-258 

[PA1]  Parnas,  D.L.  Information  Distribution  Aspects  of  Design 

Methodology,  Proceedings  of  the  IF1P  Congress,  1971 

[PA2]  Parnas,  D.L.  A  Technique  for  Software  Mod  de  Specification 
with  Examples,  CACM  15,  (May  1972  pp  330-336 

[PA3]  Parnas,  D.L  On  the  Criteria  to  be  Used  in  Decomposing 
Systems  intc  Modules,  CACM  15  (December  1972) 
pp  1053-1058 


BIBLIOGRAPHY 


203 


[PA4]  Parnas,  D.L.  Some  Conclusions  from  an  Experiment  in 
Software  Engineering  Techniques,  FJCC,  1972 

[SN]  Snowdon,  R.A.  PEARL:  An  Interactive  System  for  the  Preparation 
and  Validation  of  Structured  Programs.  Computing  Laboratory, 
University  of  Newcastle  upon  Tyne,  1971 

[vEl]  van  Emden,  M.H.  An  Analysis  of  Complexity, 

Ph.  D.  Thesis,  Mathematisch  Centrum,  Amsterdam,  1971 

[vE2]  van  Emden,  M.H.  The  heirarchical  decomposition  of 

complexity.  Machine  Intelligence  5,  Dale  and  Michie,  eds., 
Edinburgh  University  Press,  1970,  pp.  361-380 

[WA]  Watanabe,  S.  Information  theoretical  analysis 

of  multivariate  correlation.  IBM  Journal  of  Research  and 
Development,  1960,  pp. 66-82 

[W1L]  Williams,  J.W.J.  Heapsort.  CACM  7  (1964)  pp.347-348 

[WL]  Williams,  W.  and  Lambert,  J.M.  Multivariate  methods  in  plant 
ecology  I.  The  Journal  of  Ecology,  47,  pp.  83-101 

[W]  Wirth,  N.  Program  development  by  stepwise  refinement. 

CACM  14,  (April  1971),  pp.  221-227 

[W1J  Wirth,  N.  PL/360,  A  programming  language  for  the  360 
computers.  J.  ACM  15,  1  (January  1968)  pp.  37-74 

[WRH]  Wulf,  W.A.,  Russell,  D.B.  and  Habermann,  A.N.  BLISS:  A 
language  for  systems  programming.  CACM  14,  12 
(December  1971)  pp,  780-790 


APPENDIX  I:  A  MARKOV  ALGORITHM  PROCESSOR 


204 


APPENDIX  I:  A  MARKOV  ALGORITHM  PROCESSOR 


This  appendix  contains  a  development  of  a  Markov  algorithm 
processor,  based  upon  an  initial  and  informal  description.  The 
development  shows  how  assumptions  can  be  preserved  in  a  somewhat  larger 
example  than  any  which  appeared  in  Chapter  II.  The  guidelines  stated  in 
Chapter  III  are  applied  at  various  stages  of  the  development.  The 
result  includes  a  complete  program  which  inputs  and  interprets  labelled 
and  unlabelled  Markov  algorithms  and  several  modifications  to  the  basic 
program.  These  modifications  represent  several  reasonable  changes  which 
can  easily  be  made  in  the  basic  program,  but  which  would  be  difficult  or 
tedious  to  make  in  other  representations  of  the  same  program. 


The  following  document  serves  as  the  basis  for  the  development  that 
follows. 


MARKOV  ALGORITHM  INTERPRETER 


The  interpreter  is  to  be  designed  so  that  it  executes  both  labelled 
and  unlabelled  Markov  algorithms.  If  the  algorithm  is  not  terminated  by 

the  dot  convention,  then  execution  should  halt  when  the  final  rule  of 

the  algorithm  is  not  applicable,  A  "blank"  character  is  retained  as  the 

first  character  o*  the  register  so  that  all  append  rules  are  applicable. 

II.  Data  File 

A.  Parameter  Card  -  This  must  be  the  first  card  of  the  file  of 

input  cards.  If  the  card  is  blank,  the  register’s  contents 
will  be  printed  only  at  the  termination  of  the  algorithm.  Its 
contents  will  be  printed  after  the  execution  of  each 
applicable  rule  if  a  non-blank  character  appears  in  column  1. 

B.  Header  Card  -  This  card  indicates  the  title  of  the  algorithm, 
the  alphabets,  and  the  generic  variables  (if  any)  for  each 
alphabet.  The  syntax  of  the  heading  is  given  in  V.  There  are 
no  format  restrictions. 
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C.  Algorithm  -  A  single  replacement  rule  is  punched  on  each 
card  Its  format  is  as  follows: 

Cols.  i-3  Right -justified  integer  label.  Since  this 
label  has  significance  only  in  the  control  of  a 
labelled  Markov  algorithm,  it  is  optional  in 

the  case  of  an  unlabelled  one. 

Col  4  A  colon 

Cols.  5-80  <Markov  Rule>  <Successor>; 

D.  Data  -  A  single  data  card  containing  an  initial  character 
string  must  be  supplied  for  each  execution  of  the  algorithm. 
A  semicolon  indicates  the  termination  of  the  character  string. 
As  many  data  cards  as  desired  may  be  included. 

E.  Algorithm  Terminator  -  A  card  with  a  comma  (,)  punched  in  the 
first  column  indicates:  (1)  the  termination  of  the  data  for  an 
algorithm,  and  (2)  an  additional  algorithm  will  follow. 

F.  End-of-file  -  A  card  with  commas  punched  in  both  columns  one 
and  two  terminates  the  data  for  the  last  algorithm  in  the 
file. 

III.  Sample  Data  File 

The  following  unlabeled  Markov  algorithm  reverses  the  order  of  the 
characters  initially  placed  in  the  register.  The  first  character  of 
each  line,  which  is  assumed  to  represent  a  single  card,  is  assumed  to  be 
the  character  punched  in  the  first  column  of  the  card.  (Note:  The 
labels  are  optional  in  this  case.) 


REVERSE(A,B,C,D,E,F);G,H;( +,-);; 
006:++:-; 

001:-G:G-| 


002:-  +  :-; 


003:-:.; 

004:+HG:G<H; 

005::+; 


IV.  R«strictions 
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A.  The  maximum  number  of  alphabets  is  10. 

B.  The  maximum  number  of  characters  in  any  alphabet  is  30. 

C  The  maximum  number  of  generic  variables,  over  all  alphabets,  is 

10. 

D.  The  algorithm  must  have  labels  in  the  range  1  to  100. 

E.  The  register  will  hold  a  maximum  of  500  characters. 

V.  Markov  Algorithm  Syntax 

<Algorithm>  <Heading>  <Body> 

<Heading>  ::=  <Title>  <DcJaration> 

<Title>  <Character  string> 

<Declaration>  (<Alphabet>);  <Generic  Declarations  | 

<Declaration> 

(<Alphabet>);  <Generic  Declarations 

<Alphabet>  <Character>  |  <Alphabet>,<Character> 

<Generic  Declaration>  <empty>  |  <Generic  list> 

<Generic  list>  ::=  <Character>  | 

<Generic  list>,<Character> 

<Body>  <Rule>j  |  <Body>  <Rule>; 

<Rule>  ::■*  <Label>  :  <Markov  Rule>  <Successor> 

<Label>  <Digit>  |  <Label>  <Digit> 

<Markov  Rule>  <Side>  :  <Side> 

<Side>  <empty>  |  Character  $tring> 

<Character  String>  <Character>  | 

<Character  String>  <Character> 

<Successor>  <empty>  |  .  |  ,  <Label> 

<Character>  <all  characters  which  can  be  punched 
into  a  card  except  ,  ,  : ,  .  > 
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The  following  development  is  based  on  an  unpublished  program  due  to 
F.  Heymanns[H].  in  its  original  form,  many  assumptions  were  shared 
throughout  the  program,  thus  making  it  difficult  to  understand  and 
change.  The  fundamental  ideas,  however,  are  sound.  What  follows  is  an 
attempt  to  use  these  ideas  but  to  preserve  the  initial  structure  in  the 
final  program.  The  attempt  emphasizes  the  use  of  these  ideas.  Some 
readers,  however,  may  be  able  to  construct  other  programs  having  better 
structure. 


The  measure  is  used  at  various  stages  to  suggest  possible 
decompositions.  One  good  decomposition  seems  to  possess  many  of  the 
properties  suggested  by  Parnas  as  being  important  in  a  system.  That 
decomposition  bears  only  a  superficial  resemblance  to  an  initial 
decomposition  which  is  described  in  the  next  paragraph.  Below  is  an 
initial  decompostion  of  the  Markov  algorithm  processor  represented  as  a 
transition  diagram.  The  arcs  indicate  paths  for  error  conditions  as 

well  as  transitions  corresponding  to  the  occurrence  of  commas  as  the 
first  characters  of  input  cards.  ("E"  indicates  an  "error"  path.) 


— - - -  create  program  environment 

^ —  \jo  process  a  new^alRQriilim^X^ 

process  error  discovered^^^jTrocess  parameters  and  heading, 

in  parameters,  headingoi^ 

rule  input^^~~~^,  I 

^_^end-of-fijs^~~~  -process  ruiesX''' 


f  process  error  discovered  J  ^process  data  for  this  algorithm^ 
during  data  input  or 
^algorithm  execution/^ 

Note  that  each  state  requires  a  knowledge  that  cards  containing  a  comma 
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in  column  one  and  commas  in  columns  one  and  two  force  the  processor  to 

be  initialized  to  accept  a  new  algorithm  or  to  terminate.  Implicit  in 

the  diagram  is  the  ability  of  each  state  to  input  a  card  image.  Many  of 
the  interactions  caused  by  this  shared  information  can  be  eliminated  by 
removing  the  ability  to  input  a  card  image  to  a  new  state,  and  to 

include  in  this  state  all  information  regarding  the  meaning  of  cards 
containing  commas  in  the  firrt  two  columns.  This  choice  is  a  direct 
application  of  the  "information  hiding  "  principle  which  is  justified  by 

the  value  of  the  measure.  Below  is  the  new  state  diagram. 


end  of  file 
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A  map  for  the  first  stages  in  this  development  appears  below. 


:1: 


(a)  :1.1:  (210)  (b)  :1.2:  (210)  (e)  :1.3:  (211)  (d)  :1.4:  (211) 
initialize  process  input  and  process  register 

parameter  store  rules.  images  by  the 

and  heading  stored  algorithm, 

cards. 

:  1 .5:  (211)  process  end-of-file  condition 


(f)  read  and  store  a  card  image 

(g)  :3‘  (213)  process  error  occurring  in  algorithm  input  part 

(h)  A:  (213)  process  error  occurring  in  algorithm  execution  part 


(i)  :1.2.1:  (215)  (j)  :1.2.2:  (216) 

read  card  and  set  pr.  ^  inDut  and  process 


(K)  :  1.2.2.’ :  (216)  (I)  :1.2.2.2:  (217)  (m)  :1.2.2.3:  (217) 
set  failure  to  /  iterate  over  \  find  left  paren. 
ERRHEAD  /  m,  n,  o 

/  \ 

(n)  :1.2.2A:  (218)  (o)  :1.2.2.5:  (219) 

process  alphabet  set  failure  to  RULES 

and  generics. 
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(a)  :1.1: 

assumptions:  :1.1:  PROVIDE  ALL  NECESSARY  INITIALIZATIONS; 

effects  and 

post-conditions:  all  necessary  initializations  have  been  made 

(b)  :  1.2: 

assumptions:  requires  the  ability  to  invoke  :3:(  ERf  OP,  with  a 

string  message,  requires  ability  to  invokj  NEXTCARD 
which  makes  a  new  card  image  available,  i.e. 

r.bility  to  invoke  :2:  and  returns  to  the  invoker 
only  if  a  card  for  the  current  algorithm  is 

available,  NEXTCHAR  is  the  vclue  of  the  character 
which  immediately  follows  the  character  of  the 
current  card  image  produced  by  the  last  call  of 
NEXTCHAR 

:1.2:  INPUT  AND  PROCESS  THE  PARAMETER  CARD; 

INPUT  AND  PROCESS  THE  HEADING  CARD; 

effects  and 

post-conditions:  parameter  card  and  heading  card  have  been  correctly 

processed 
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(c)  :1.3: 

assumptions:  requires  the  ability  to  invoke  :3:,  ERROR,  with  a 

string  message,  requires  ability  to  invoke  NEXTCARD 
which  makes  a  new  card  image  available,  i.e. 

ability  to  invoke  :2:  and  returns  to  the  invoker 
only  if  a  card  for  the  current  algorithm  is 

available,  NEXTCHAR  is  the  value  of  the  character 
which  immediately  follows  the  character  of  the 
current  card  image  produced  by  the  last  call  of 
NEXTCHAR 

:  1 .3:  INPUT  AND  PROCESS  THE  RULES  FOR  THIS 
ALGORITHM; 

effects  and 

postconditions:  all  rules  for  this  algorithm  have  been  inputted 

(d)  -A A: 

assumptions:  requires  ability  to  invoke  NEXTCARD  which  makes  a 

new  card  image  available,  i.e.  ability  to  invoke 
:2:  and  returns  to  the  invoker  only  if  a  card  for 
the  current  algorithm  is  available,  NEXTCHAR  is  the 
value  of  the  character  which  immediately  follows  the 
character  of  the  current  card  image  produced  by  the 
last  call  of  NEXTCHAR 

:1  A:  PROCESS  THE  DATA  IMAGES  WITH  RESPECT  TO  THE 
STORED  ALGORITHM; 

effects  and 

postconditions:  all  data  images  for  this  algorithm  have  been 

processed 

(e)  :  1.5: 

assumptions:  an  end-of-file  condition  has  occurred 

:  1-5:  PROCESS  END-OK-FILE  CONDITION  AND  TERMINATE; 

effects  and 

post-conditions:  the  Markov  algorithm  processor  has  been  terminated 
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(f)  :2: 

assumptions:  requires  the  ability  to  invoke  the  termination  of 

the  entire  program,  i.e.  :  1 .5:  ENDOFFILE,  requires 
the  ability  to  invoke,  ALG1N1T  (rl.l.l  )  the  start 

of  processing  for  a  new  algorithm,  CP  is  an  index 

into  C  and  indexes  the  last  character  which  was 

produced  as  a  value  from  NEXTCHAR.  After  an 

execution  of  NEXTCARD,  :2:,  CP  must  equal  0,  write 
access  required  for  CP,  C[l]  ...  C[80]  contains  the 

characters,  in  order,  of  the  card  image  which  is 

inputted  as  a  result  of  the  last  execution  of 
GETIMAGE,  requires  read  access  to  C,  requires 

ability  to  invoke  GETIMAGE  which  inputs  a  card  and 

returns  to  the  caller  only  if  a  card  was  inputted, 
in  columns  1  and  2  indicate  that  the  program  is 
to  terminate  and  a  in  column  1  only  indicates 
that  a  new  algorithm  is  to  be  processed 

:2:  READ  A  CARD  AND  STORE  THE  80  CHARACTERS  IN 
SUCCESSIVE  LOCATIONS  OF  THE  ARRAY  C,  I.E. 

C[1],...,C[80]  I.E.  GETIMAGE. 

if  C[l]  =  COMMA  then 
begin 

if  C[2]  =  COMMA  then  invoke  end-of-file  state 

else  invoke  algorithm  initialization  state 
end 

else  CP  *-  0 


a  new  card  image  has  been  read  and  the  appropriate 
transition  made. 


effects  and 
post-conditions: 
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(g)  :3: 

assumptions:  requires  ability  to  invoke  NEXTCARD  which  makes  a 

new  card  image  available,  i.e.  ability  to  invoke 
:2:  and  returns  to  the  invoker  only  if  a  card  for 
the  current  algorithm  is  available,  requires  ability 
to  print  the  string  argument  which  is  passed  as  the 
parameter  to  ERROR,  ability  to  perform  printing 
operations 

:3:  AN  ERROR  WAS  DISCOVERED  BY  THE  ALGORITHM  INPUT 
PART; 

INDICATE  THE  ERROR; 

READ  AND  PRINT  ALL  THE  REMAINING  IMAGES  FOR  THIS 
ALGORITHM; 

while  true  do 
begin 

READCARD; 

PRINTCARD 

end; 

effects  and 

post-conditions:  string  parameter  has  been  printed  along  with  all 

remaining  card  images  for  the  algorithm  being 
processed 

(h)  :4: 

assumptions:  requires  ability  to  invoke  NEXTCARD  which  makes  a 

new  card  image  available,  i.e.  ability  to  invoke 

:2:  and  returns  tc  the  invoker  only  if  a  card  for 
the  current  algorithm  is  available,  NEXTCHAR  is  the 
value  of  the  character  which  immediately  follows  the 
character  of  the  current  card  image  produced  by  the 
last  call  of  NEXTCHAR,  requires  ability  to  invoke 

:1.4:  which  processes  the  remaining  data  images  for 
this  algorithm,  ability  to  perform  printing 

operations 

:4:  AN  ERROR  WAS  DISCOVERED  BY  THE  ALGORITHM 
EXECUTION  PART; 

INDICATE  THE  ERROR; 

READ  A  NEW  DATA  CARD  ; 

INVOKE  THE  ALGORITHM  EXECUTION  PART; 


a  new  data  image  has  been  read  and  the  execution 
part  has  been  processed 


effects  and 
post-conditions: 
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The  object/assumption  table  for  these  objects  is: 

I  23456789  101 1 12131415 


(a) 

l-  i: 

(b) 

I-  2: 

(0 

1  ■  3* 

(d) 

1-4* 

(e) 

I-  5** 

(f) 

2' 

(g) 

2' 

(h) 

45 

1)  requires  the  ability  to  invoke  :3:,  ERROR,  with  a  string  message 

2)  requires  ability  to  invoke  NEXTCARL)  which  makes  a  new  card  image 
available,  i.e.  ability  to  invoke  :2:  and  returns  to  the  invoker 

only  if  a  card  for  the  current  algorithm  is  available 

3)  NEXTCHAR  is  the  value  of  the  character  which  immediately 
follows  the  character  of  the  current  card  image  produced  by 
the  last  call  of  NEXTCHAR 

4)  an  end-of-file  condition  has  occurred 

5)  requires  the  ability  to  invoke  the  termination  of  the  entire 

program,  i.e.  :1.5:  ENDOFFILE 

6)  requires  the  ability  to  invoke,  ALGINIT  (:1.1.1:) 

the  start  of  processing  for  a  new  algorithm 

7)  CP  is  an  index  into  C  and  indexes  the  last  character  which 

was  produced  as  a  value  from  NEXTCHAR.  After  an  execution 
of  NEXTCARD,  :2:,  CP  must  equal  0 

8)  write  access  required  for  CP 

9)  C[l]  ...  C[80]  contains  the  characters, 

in  order,  of  the  card  image  which  is  inputted  as  a  result 
of  the  last  execution  of  GETIMAGE 

10)  requires  read  access  to  C 

11)  requires  ability  to  invoke  GETIMAGE  which  inputs  a  card 
and  returns  to  the  caller  only  if  a  card  was  inputted 

12)  ,  in  columns  1  and  2  indicate  that  the  program  is  to  terminate 
and  a  ,"  in  column  1  only  indicates  that  a  new  algorithm 

is  to  be  processed 

13)  requires  ability  to  print  the  string  argument  which  is  passed  as 

the  parameter  to  ERROR 

14)  ability  to  perform  printing  operations 

15)  requires  ability  to  invoke  :1.4:  which  processes  the  remaining 

data  images  for  this  algorithm 
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A  good  decomposition  for  these  objects  is 
((a)  ((•)  ((f)  ((  g  ,  h  )  ((d)  (  b  ,  c  ))  .97  )  1.08  )  .14  )  .20  )  0 
Here,  objects  (g)  and  (h)  process  errors,  objects  (b)  and  (c)  input  the 
algorithm  and  object  (d)  interprets  it.  Not  surprisingly,  the  lack  of 

assumptions  made  by  the  initialization  part  leaves  the  entropy  loading 
figure  at  0.  Next,  :  1 .2:  is  elaborated 


(i)  :1.2.1: 

assumptions:  requires  ability  to  invoke  NEXTCARD  which  makes  a 

new  card  image  available,  i.e.  ability  to  invoke 
:2:  and  returns  to  the  invoker  only  if  a  card  for 
the  current  algorithm  is  available,  NEXTCHAR  is  the 

value  of  the  character  which  immediately  follows  the 
character  of  the  current  card  image  produced  by  the 

last  call  of  NEXTCHAR,  requires  write  access  to  PR, 

pr  *=  true  means  "print  the  register  after  each 
successful  application  of  a  rule;  otherwise  d  not 

print  the  register  after  each  successful  application 
of  a  rule 

-.1.2.1:  READ  A  NEW  CARD  IMAGE; 

SET  THE  FUNCTION  pr  TO  INDICATE  WHETHER  OR  NOT  THE 
REGISTER  CONTENTS  SHOULD  BE  PRINTED,  I.E. 

NEXTCARD; 

pr  <-  if  NEXTCHAR  =  "1"  then  true  else  false; 


pr  -  true  if  the  register  is  to  be  printed  after 
each  successful  rule  application;  false  otherwise 


effects  and 
post-conditions: 


APPENDIX  I:  A  MARKOV  ALGORITHM  PROCESSOR 


216 


(j)  :  1.2.2: 

assumptions:  requires  the  ability  to  invoke  :3:,  ERROR,  with  a 

string  message,  requires  ability  to  invoke  NEXTCARD 
which  makes  a  new  card  image  available,  i.e. 
ability  to  invoke  :2:  and  returns  to  the  invoker 
only  if  a  card  for  the  current  algorithm  is 
available,  NEXTCHAR  is  the  value  of  the  character 
which  immediately  follows  the  character  of  the 
current  card  image  produced  by  the  last  call  of 
NEXTCHAR,  MAXA  equals  the  maximum  number  of 
alphabets  permitted  for  an  algorithm,  requires  read 
access  to  MAXA,  ability  to  set  the  failure  routine 
for  NEXTCHAR,  i.e.  FAIL  can  be  assigned  a  name 
which  can  be  invoked  if  no  more  characters  are 
available  from  NEXTCHAR 

:  1.2.2:  INPUT  AND  PROCESS  THE  HEADING  CARD  IMAGE; 

effects  and 

post-conditions:  The  heading  card  image  has  been  correctly  processed 

(k)  :  1.2.2. 1 : 

assumptions:  ability  to  set  the  failure  routine  for  NEXTCHAR, 

i.e.  FAIL  can  be  assigned  a  name  which  can  be 
invoked  if  no  more  characters  are  available  from 
NEXTCHAR,  requires  ability  to  invoke  NEXTCARD  which 
makes  a  new  card  image  available,  i.e.  ability  to 
invoke  :2:  and  returns  to  the  invoker  only  if  a  card 
for  the  current  algorithm  is  available, 

:1. 2.2.1:  SET  THE  FAILURE  ROUTINE  FOR  NEXTCHAR  TO  BE 
ERRHEAD;  NEXTCARD: 

effects  and 

post-conditions:  ERRHEAD  has  been  set  as  the  failure  routine  for 

NEXTCHAR  and  a  new  card  image  has  been  read 


APPENDIX  I:  A  MARKOV  ALGORITHM  PROCESSOR 


217 


(I)  :  1.2. 2. 2: 

assumptions: 


effects  and 
post-conditions: 

(m)  :1.2.2.3: 

assumptions: 


effects  and 
post-conditions: 


a  failure  routine  has  been  set  if  NEXTCHAR  cannot 
provide  additional  characters  from  the  current 
image,  either  no  alphabets  have  been  processed  of 
all  alphabets  processed  have  been  correct 

: i .2.2.2: 

repeat 

begin 

:  1 .2.2.3:  ; 

:  1.2.2. A:  ; 

:1.2.2.5 

end 

until  false; 


The  heading  card  has  been  correctly  processed  and 
is  error  free. 


a  failure  routine  has  been  set  if  NEXTCHAR  cannot 
provide  additional  characters  from  the  current 
image,  read  access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN, 
CLOSE  which  contain  the  values  of 

")",  assumes  write  access  to  CHAR,  assumes 
read  access  to  CHAR,  NEXTCHAR  is  the  value  of  the 
character  which  immediately  follows  the  character  of 
the  current  card  image  produced  by  the  last  call  of 
NEXTCHAR,  a  failure  routine  has  been  set  if  NEXTCHAR 
cannot  provide  additional  characters  from  the 
current  image 

:  1 .2.2.3:  SCAN  FOR  A  LEFT  PARENTHESIS,  I.E. 

repeat 

CHAR  «-  NEXTCHAR 
until  CHAR  »  OPEN; 


CHAR  is  an  open  parenthesis. 
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(n)  :1.2.2.4s 

assumptions: 


effects  and 
post-conditions: 


ability  to  set  the  failure  routine  for  NEXTCHAR, 
i.e.  FAIL  can  be  assigned  a  name  which  can  be 
invoked  if  no  more  characters  are  available  from 
NEXTCHAR,  assumes  write  access  to  CHAR,  assumes  read 
access  to  CHAR,  requires  the  ability  to  invoke  :3:, 
ERROR,  with  a  string  message,  NEXTCHAR  is  the  value 
of  the  character  whicn  immediately  follows  the 
character  of  the  current  card  image  produced  by  the 
last  call  of  NEXTCHAR,  MAX  A  equals  the  maximum 
number  jf  alphabets  permitted  tor  an  algorithm, 
requires  read  access  to  MAXA,  NA  equals  the  number 
of  alphabets  which  have  been  processed  thus  far  for 
the  current  algorithm,  requires  read  accesss  to  NA, 
requires  write  access  to  NA,  read  access  to  DOT, 
COMMA,  COLON,  SEMI,  OPEN,  CLOSE  which  contain  the 
values  of  T,  ERRHEAD 

assumes  compete  control  when  invoked  and  handles 
error  messages  and  further  processing,  requires 
ability  to  invoke  STORGEN  which  stores  the  content 
of  CHAR,  if  legal,  otherwise  invokes  the  apporpriate 
error,  requires  ability  to  invoke  STORALPH,  which 
stores  the  alphabet  character  if  all  requirements 
are  met, otherwise  STORALPH  invokes  appropriate  error 
routines,  requires  ability  to  invoke  ALPHFIN  which 
cmpletcs  any  needed  processing  after  an  entire 
alphabet  has  been  stored 

:1. 2.2.4:  PROCESS  AN  ALPHABET  AND  ITS  GENERICS; 

A  single  alphabet  and  its  generics  has  been 
correctly  processed 
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(o)  1.2. 2.5: 

as;umptions:  ability  to  set  the  failure  routine  for  NEXTCHAR, 

i.e.  FAIL  can  be  assigned  a  name  which  can  be 
invoked  if  no  more  characters  are  available  from 
NEXTCHAR,  requires  ability  to  invoke  RULES  which 
names  the  rule  input  part,  but  since  RULES  is  a 
label  in  the  main  program  a  go  to  statement  can  be 
used 

:1. 2.2.5:  SETFAIL(RULES); 

effects  and 

postconditions:  failure  routine  for  NEXTCHAR  has  been  set  to  the 

next  stage  of  processing 

Below  is  map  for  the  elaboration  of  :1.2.2.4: 
and  several  objects  used  by  the  elaboration. 


(p)  :  1 .2.2.4. 1 :  (220)  (q)  :1.2.2.4.2:  (221)  (r)  :1.2.2.4.3:  (222) 

process  alphabet  part.  process  generic  terminate  processing 

part.  for  an  alphabet. 


(s)  :  1 1 :  (225)  get  next  character 

(t)  :12:  (226)  store  a  generic  for  the  current  alphabet 

(u)  :13:  (227)  store  a  character  into  the  current  alphabet 

(v)  :14:  (228)  terminate  processing  for  current  alphabet 

(w)  :15:  (228)  test  whether  space  exhausted. 

(x)  :  1 6:  (229)  test  whether  character  is  a  legal 

alphabetic  or  generic 

(y)  :  1 7:  (229)  test  whether  generic  has  already  been  used 

(z)  :i 8:  (230)  test  whether  character  has  already  occurred 

in  this  alphabet. 
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(p)  :1.2.2A1: 

assumptions:  ERRHEAD  assumes  compete  control  when  invoked  and 

handles  error  messages  and  further  processing, 

NEXTCHAR  is  the  value  of  the  character  which 
immediately  follows  the  character  of  the  current 
card  image  produced  by  the  last  call  of  NEXTCHAR,  NA 
equals  the  number  of  alphabets  which  have  been 
processed  thus  far  for  the  current  algorithm, 
requires  read  accesss  to  NA,  MAXA  equals  the  maximum 
number  of  alphabets  permitted  for  an  algorithm, 
requires  read  access  to  MAXA,  requires  write  access 
to  NA,  assumes  write  access  to  CHAR,  assumes  read 
access  to  CHAR,  requires  the  ability  to  invoke  :3:, 
ERROR,  with  a  string  message,  ability  to  set  the 

failure  routine  for  NEXTCHAR,  i.e.  FAIL  can  be 

assigned  a  name  which  can  be  invoked  if  no  more 
characters  are  available  from  NEXTCHAR,  read  access 
to  DOT,  COMMA,  COLON,  SEMI,  OPEN,  CLOSE  which 
contain  the  values  of  .  ,  ,  ,  :  ,  5 ,  \  >  >  > 

requires  read/write  access  to  NOIT,  which  controls  a 
loop  that  process  alphabets,  requires  ability  to 
invoke  STORALPH,  which  stores  the  alphabet  character 
if  all  requirements  are  met, otherwise  STORALPH 

invokes  appropriate  error  routines 

:  1.2.2. A.  1:  PROCESS  ALPHABET  PART  - 

if  NA  +  1  >  MAXA  then  ERRORC’TOO  MANY  ALPHABETS"); 
SETFAILfERRHEADNAME); 

NOIT  *-  false; 

repeat 

begin 

CHAR  «-  NEXTCHAR; 

STORALPH; 

CHAR  NEXTCHAR; 
if  CHAR  i  COMMA  then 
begin 

if  CHAR  t  CLOSE  or  NEXTCHAR  +  SEMI  then 
ERRHEAD 
else 

NOIT  «-  true 
end 
end 

until  NOIT; 

NA  NA  +  1; 


effects  and 
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post-conditions: 

(q)  :1.2.2A2: 

assumptions: 


effects  and 
post-conditions: 


a  single  alphabet  has  been  successfully  processed 
and  stored,  NA  equals  the  number  of  alphabets  which 
have  been  processed  thus  far  for  the  current 
algorithm 


assumes  write  access  to  CHAR,  assumes  read  access 
to  CHAR,  read  access  to  DOT,  COMMA,  COLON,  SEMI, 
OPEN,  CLOSE  which  contain  the  values  of 

"(",  T,  NEXTCHAR  is  the  value  of  the 
character  which  immediately  follows  the  character  of 
the  current  card  image  produced  by  the  last  call  of 
NEXTCHAR,  requires  read/write  access  to  M0IT1,  which 
controls  a  loop  that  processes  generics,  ERRHEAD 
assumes  compete  control  when  invoked  and  handles 
error  messages  and  further  processing,  requires 
ability  to  invoke  STORGEN  which  stores  the  content 
of  CHAR,  if  legal,  otherwise  invokes  the  apporpriate 
error 

:1.2.2A2:  PROCESS  GENERIC  VARIABLES  FOR  THIS 
ALPHABET  - 

CHAR  «-  NEXTCHAR; 

NOI T1  «-  false; 
if  CHAR  it  SEMI  then 
bogin 
repeat 
begin 
STORGEN; 

CHAR  «-  NEXTCHAR; 
if  CHAR  t  COMMA  then 
begin 

if  CHAR  t  SEMI  then  ERRHEAD 

else  N0IT1  <-  true 

end 

el:e  CHAR  <-  NEXTCHAR 
end 

until  N0IT1; 
end; 


the  generic  part  of  the  alphabet  has  been 
successfully  processed. 
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(r)  :1.2.2A3: 

assumptions: 


effects  and 
post-conditions: 


requires  ability  to  invoke  ALPHF1N  which  cmpletes 
any  needed  processing  after  an  entire  alphabet  has 
been  stored 

:  1.2.2 A3:  ALPHFIN; 


final  processing  for  an  alphabet  is  completed 
The  object/assumption  table  for  this  expansion  is 


(i) 

(j) 

00 

(l) 

(m) 

(n) 

(o) 
(P) 

(q) 

(D 

1) 

2) 


3) 


4) 

5) 

6) 
7) 


8) 

9) 


10) 

11) 

12) 


I  23456789  101 II2I3I4I5I6I7I8I9202I2223242526272829303I323334353637: 


I  • 

2* 

2-  1: 

2-  2* 
2-3! 

2'  4: 

2-  55 
!•  2-  2-  4  I • 
1  ■  2-  2-  4-  2' 
1*2-2-  4-  3! 


1  I 
I  I  I 
I 


I  I 


I  I 


I  I 


I  I  I 


I  I  I 


I  I  I 


I 

I  I  I  I 

III  I  I  I  I  I  II 

I 

III  I  I  I  I  I  I 

I  I  I  I  II 

I 


requires  the  ability  to  invoke  :3:,  ERROR,  with  a  string  message 
requires  ability  to  invoke  NEXTCARD  which  makes  a  new  card  image 
available,  i.e.  ability  to  invoke  :2:  and  returns  to  the  invoker 
only  if  a  cara  for  the  current  algorithm  is  available 
NEXTCHAR  is  the  value  Of  the  character  which  immediately 
follows  the  character  of  the  current  card  'm?ge  produced  by 
the  last  call  of  NEXTCHAR 
an  end-of-file  condition  has  occurred 
requires  the  ability  to  invoke  the  termination  of  the  entire 
program,  i.e.  :1.5:  END0FF1LE 
requires  the  ability  to  invoke,  ALG1NIT  (:1.1.1:) 

the  start  of  processing  for  a  new  algorithm 
CP  is  an  index  into  C  and  indexes  the  last  character  which 
was  produced  as  a  value  from  NEXTCHAR.  After  an  execution 
of  NEXTCARD,  :2:,  CP  must  equal  0 
write  access  required  for  CP 
C[l]  ...  C[80]  contains  the  characters, 

in  order,  of  the  card  image  which  is  inputted  as  a  result 
of  the  last  execution  of  GETIMAGE 
requires  read  access  to  C 

requires  ability  to  invoke  GETIMAGE  which  inputs  a  card 
and  returns  to  the  caller  only  if  a  card  was  inputted 

in  columns  1  and  2  indicate  that  the  program  is  to  terminate 
and  a  in  column  1  only  indicates  that  a  new  algorithm 
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is  to  be  processed 

13)  requires  ability  to  print  the  string  argument  which  is  passed  as 

the  parameter  to  ERROR 

14)  ability  to  perform  printing  operations 

15)  requires  ability  to  invoke  :1.4:  which  processes  the  remaining 

data  images  for  this  algorithm 

16)  requires  write  access  to  PR 

17)  pr  =  true  means  "print  the  register  after  each  successful 
application  of  a  rule;  otherwise  d  not  print  the  register 
after  each  successful  application  of  a  rule 

18)  MAXA  equals  the  maximum  number  of  alphabets  permitted  for 

an  algorithm 

19)  requires  read  access  to  MAXA 

20)  ability  to  set  the  ‘ailure  routine  for  NEXTCHAR,  i.e.  FAIL 

can  be  assigned  a  nam.3  which  can  be  invoked  if  no  more  characters 
are  available  from  NEXTCHAR 

21)  NG  contains  the  number  of  generic  variables  encountered 
for  the  current  algorithm 

22)  CG[i],  1  <  i  <  NG,  equals  the  i-th  generic  variable 
encountered  for  the  current  algorithm 

23)  AG[i],  1  <  i  <  NG,  equals  the  alphabet  name  which 
CG[i]  is  a  generic  variable 

24)  a  failure  routine  has  been  set  if  NEXTCHAR  cannot 
provide  additional  characters  from  the  current  image 

25)  read  access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN,  CLOSE  which 

contain  the  values  of  V,  ")" 

26)  assumes  write  access  to  CHAR 

27)  assumes  read  access  to  CHAR 

28)  requires  ability  to  invoke  RULES  which  names  the  rule  input 
part,  but  since  RULES  is  a  label  in  the  main  program 

a  go  to  statement  can  be  used 

29)  ERRHEAD  assumes  compete  control  when  invoked 

and  handles  error  messages  and  .urther  processing 

30)  NA  equals  the  number  of  alphabets  which  have  been  processed 

thus  far  for  the  current  algorithm 

31)  requires  read  accesss  to  NA 

32)  requires  write  access  to  NA 

33)  requires  read/write  access  to  NOIT,  which  controls  a 
loop  that  process  alphabets 

34)  require?  ability  to  invoke  STORALPH,  which  stores  the  alphabet 
character  if  all  requirements  are  met, otherwise  STORALPH 
invokes  appropriate  error  routines 

35)  requires  read/write  access  to  NOIT  1,  which  controls  a  loop 

that  processes  generics 

36)  requires  ability  to  invoke  STORGEN  which  stores  the  content 

of  CHAR,  if  legal,  otherwise  invokes  the  apporpriate 
error 

37)  requires  ability  to  invoke  ALPHFIN  which  cmpletes  any 
needed  processing  after  an  entire  alphabet  has  been 
stored 
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38)  either  no  alphabets  have  been  processed  of  all  alphabets 
processed  have  been  correct 

This  table  involves  two  stages  of  elaboration.  RLB  and  RUB  for  the 

elaboration  of  : i .2:  to  :  1.2. 1 :  and  :  1.2.2:  are 

RUB:  ((a)  ((e)  ((f)  «  g  ,  h  )  ((d)  (  b  ,  c  ))  .94  )  1.06  )  .14  )  .19  )  0 

RLB:  ((a)  ((e)  ((f)  «  g  ,  h  )  ((d)  (  b  ,  c  »  .94  )  .99  )  .07  )  .10  )  0 

but  the  actual  expansion  leads  to 

((a)  ((•)  ((f)  ((  g  ,  h  )  ((d)  ((c)  (  i  ,  j  )  1.0  )  .94  )  .99  )  .07  )  .10  )  0 
Expanding  :  1 .2.2:  leads  to  RLB  and  RUB 

RUB:  ((a)  ((e)  ((f)  «  g  ,  h  )  ((d)  ((c)  (  i  ,  j  )) 

.83  )  1.23  )  .79  )  .93  )  .12  )  .16  )  0 

RLB:  ((a)  ((e)  ((f)  ((  g  ,  h  )  ((d)  ((c)  (  i  ,  j  )) 

0  )  .88  )  .86  )  .93  )  .04  )  .05  )  0 
but  the  actual  entropy  loadings  are 

((a)  ((e)  ((f)  ((  g  ,  h  )  ((d)  ((c)  ((i)  (  k  ,  I  ,  m  ,  n  ,  o)) 

1.33  )  1.59  )  1.36  )  1.48  )  .12  )  .16  )  0 

A  better  decomposition  is 

((a)  ((e)  ((f)  (0)  ((  k  ,  o  )  ((  m  ,  n  )  ((i)  (  d  ,  c,  g  ,  h  )) 

1.33  )  1.20  )  1.33  )  .54  )  .36  )  .12  )  0 

After  examining  RLB  and  RUB  for  the  expansion  of  :  1 .2.2.4:,  the 
following  good  decomposition  was  found 


((a)  ((•)  ((r)  ((f)  ((I)  ((  k  ,  o  )  ((  m  ,  q  ,  p  ) 

((i)  ((  d  ,  c,  g  ,  h  ))  1.34  )  1.12  )  1.26  )  .49  )  .09  )  .12  )  .16  )  0 
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The  major  parts  in  this  decomposition  are  (1)  the  algorithm 
interpretation  and  input  parts  along  with  the  error  processing  that  can 
occur  there  (  c  ,  d  ,  g  ,  h  );  (2)  alphabet  and  generic  input  parts  (  m 
,  p  ,  q  );  and  (3)  the  parts  that  set  failure  routines. 


(s)  :1 1: 

assumptions:  requires  ability  to  invoke  FAIL  which  correctly 

determines  which  objects  assume  control,  a  failure 
routine  has  been  set  if  NEXTCHAR  cannot  provide 
additional  characters  from  the  current  image,  C[l] 
...  C[80]  contains  the  characters,  in  order,  of  the 

card  image  which  is  inputted  as  a  result  of  the  last 
execution  of  GETIMAGE,  requires  read  access  to  C,  CP 
is  an  index  into  C  and  indexes  the  last  character 
which  was  produced  as  a  value  from  NEXTCHAR.  After 
an  execution  of  NEXTCARD,  :2:,  CP  must  equal  0,  read 
access  required  for  CP,  write  access  required  for  CP 

:  1 1 :  NEXTCHAR:  CP  <-  CP  +  1; 

if  CP  >  80  then 

FAIL 

else 

NEXTCHAR  <-  CCCP]; 


effects  and 

postconditions:  the  value  of  :  1 1 :  is  set  to  be  C[CP],  i.e.  the 

next  available  character  in  the  current  image,  and 
if  no  more  characters  are  available,  the  failure 
luutirie  is  execuied 
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(t)  :  1 2: 

assumptions:  requires  the  ability  to  invoke  :3:,  ERROR,  with  a 

string  message,  NA  equals  the  number  of  alphabets 
which  have  been  processed  thus  far  for  the  current 

algorithm,  requires  read  accesss  to  NA,  read  and 
write  access  required  for  the  variable  1,  requires 

ability  to  invoke  TESTLEGAL  which  returns  only  if 

CHAR  is  not  requires  ability  to 

invoke  TESTGEN  which  returns  only  if  CHAR  is  not 
equal  to  an  already  used  generic  variable  for  this 

algorithm,  A  names  a  one-dimensional  array,  which 
from  UPA  to  its  upper  bound  contains  alphabetic 

characters,  requires  read  access  for  A,  AG[i],  1  £  i 
<  NG,  equals  the  alphabet  name  which  CG[i]  is  a 

generic  variable,  requires  write  access  to  CG, 

CG[i],  1  <  i  <  NG,  equals  the  i-th  generic  variable 

encountered  for  the  current  algorithm,  NG  contains 
the  number  of  generic  variables  encountered  for  the 
current  algorithm,  requires  read  access  to  NG, 

requires  write  access  to  NG,  requires  write  access 
to  AG,  assumes  read  access  to  CHAR,  CHAR  contains 
the  next  unstored  character  from  the  alphabet  or 
generics  being  currently  processed,  AL[  1  ] 

Al[NA]  names  the  index  of  the  lower  bound  of  the 
characters  in  an  alphabet  i.e.  AL[i]  is  the  lower 
bound  for  the  i-th  alphabet  and  AL[i-l]  is  the  upper 

bound  for  that  alphabet,  where  AL[0]  equals  the 
initial  value  plus  1  of  UPA,  requires  read  access  to 
AL,  requires  ability  to  invoke  ERRGEN,  which  assumes 
control  and  invokes  an  appropriate  error  routine, 

:12:  STORGEN 

TESTLEGAL; 

TESTGEN; 

for  I  <-  UPA  step  1  until  Al[0]  -1  do 
if  CHAR  =  A[I]  then  ERRGEN; 

NG  <-  NG  +  1; 

if  NG  >  MAXG  then  ERROR  ("TOO  MANY  GENERIC 
VARIABLES"); 

CG[NG]  CHAR; 

AG[NG]  NA; 

effects  and 

post-conditions:  content  of  CHAR  has  been  stored  as  a  generic 

variable  with  respect  to  the  alphabet  currently 
being  processed 
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(u)  :  1 3: 

assumptions  requires  ability  to  invoke  TESTLEGAL  which  returns 

only  if  CHAR  is  not  V,  V,  requires 

ability  to  invoke  TESTGF.N  which  returns  only  if  CHAR 
is  not  equal  to  an  already  used  generic  variable  for 
this  algorithm,  requires  ability  to  invoke  TESTAL 
which  returns  only  if  CHAR  is  not  equal  to  a 
character  which  has  already  occurred  in  the  alphabet 
currently  being  processed,  requires  aoility  to 
invoke  TEST  which  returns  only  if  there  storage 
space  as  indicated  by  the  values  of  LPA  and  UPA,  UPA 
names  the  last  cell  of  an  array  into  which  an 
alphabetic  character  was  stored,  counting  from  the 
top  of  some  one-dimensional  array.  UPA  is 
decremented  by  1  each  time  an  available  cell  needs 
to  be  named,  requires  read  access  to  UPA,  requires 
write  access  to  UPA,  A  names  a  one-dimensional 
array,  which  from  UPA  to  its  upper  bound  contains 
alphabetic  characters,  requires  write  access  for  A, 
assumes  read  access  to  CHAR,  CHAR  contains  the  next 
unstored  character  from  the  alphabet  or  generics 
being  currently  processed 

:  13:  STORALPH 

TESTLEGAL; 

TtSTGEN; 

TESTAL; 

UPA  <-  UPA  -  1; 

TEST; 

A[UPA]  ♦-CHAR; 


enacts  and 

postconditions:  the  contents  of  CHAR  has  been  correctly  stored  as 

an  alphabet  character  in  the  current  alphabet 
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(v)  :14: 
assumptions: 


effects  and 
post-conditions: 

(w)  :  1 5: 

assumptions: 


effects  and 
post-conditions: 


AL[l]  ...  AL[NA]  names  the  index  of  the  lower 
bound  of  the  characters  in  an  alphabet,  i.e.  AL[i] 
is  the  lower  bound  for  the  i-th  alphabet  and  AL[i-l] 
is  the  upper  bound  for  that  alphabet,  where  AL[0] 
equals  the  initial  value  plus  1  of  UPA,  requires 
write  access  to  AL,  NA  equals  the  number  of 
alphabets  which  have  been  processed  thus  far  for  the 
current  algorithm,  requires  read  accesss  to  NA,  UPA 
names  the  last  cell  of  an  array  into  which  an 
alphabetic  character  was  stored,  counting  from  the 
top  of  some  one-dimensional  array.  UPA  is 
decremented  by  1  each  time  an  available  cell  needs 
to  be  named,  requires  read  access  to  UPA 

:14:  ALPHF1N 

AL[NA]  <-  UPA; 


lower  bound  for  alphabet  NA  has  been  set 


requires  the  ability  to  invoke  :3:,  ERROR,  with  a 
string  message,  UPA  names  the  last  cell  of  an  array 
into  which  an  alphabetic  character  was  stored, 
counting  from  the  top  of  some  one-dimensional  array. 
UPA  is  decremented  by  1  each  time  an  available  cell 
needs  to  be  named,  requires  read  access  to  UPA,  LPA 
names  the  las  cell  of  an  array  into  which  rules  are 
stored,  counting  from  the  lower  bound  of  a 
one-dimensional  array  .  LPA  is  incremented  by  one 
each  time  an  available  cell  needs  to  be  named, 
requires  read  access  to  LPA,  LPA  and  UPA  are  index 
variables  for  the  same  array 

:  15:  TEST  IE. 
if  LPA  >  UPA  then 

ERRORCALGORITHM  TEXT  TOO  LARGE  OR  TOO  MANY 
ALPHABET 

CHARACTERS"); 

there  is  an  available  storage  location  for  a  rule 
rule  character  or  an  alphabetic  character  or  a 
generic 


I 


(x)  :16: 

assumptions:  read  access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN,  CLOSE 

whicn  contain  the  values  of 

")",  requires  the  ability  to  invoke  :3:,  ERROR,  with 
a  string  message,  assumes  read  access  to  CHAR,  CHAR 
contains  the  next  unstored  character  from  the 
alphabet  or  generics  being  currently  processed 

:i6: 

TESTLEGAL,  I.E. 

if  CHAR  =  COLON  or  CHAR  =  DOT  or  CHAR  =  COMMA  or 
CHAR  =  SEMI  then 

ERRORHLLEGAL  CHARACTER’  ); 

effects  and 

post-conditions:  CHAR  is  not  a  colon,  period,  comma,  or  semicolon 

(y)  :17: 

assumptions:  assumes  read  access  to  CHAR,  CHAR  contains  the  next 

unstored  character  from  (lie  alphabet  or  generics 
being  currently  processed,  NG  contains  the  number  of 
generic  variables  encountered  for  the  current 

algorithm,  requires  rend  access  to  NG,  CG[i],  1  <  i 
<  NG,  equals  the  i-th  generic  variable  encountered 
for  the  current  algorithm,  requires  read  access  to 
CG,  requires  ability  to  invoke  E.RRGEN,  which  assumes 
control  and  invokes  an  appropriate  error  routine, 
requires  read/wnte  access  to  j 

17:  TESTGEN  I.E. 
for  J  «-  1  step  1  until  NG  do 

if  CHAR  =  CG[ J]  then  ERRGtN; 

wtiecis  and 

post-conditions:  CHAR  has  not  occurred  beiore  as  a  generic  variable 


APPENDIX  I:  A  MARKOV  ALGORITHM  PROCESSOR 


230 


(z)  :  1 8: 

assumptions:  requires  read/write  access  to  K,  NA  equals  the 

number  of  alphabets  which  have  been  processed  thus 
far  for  the  current  algorithm,  requires  read  accesss 
to  NA,  requires  the  ability  to  invoke  :3:,  ERROR, 
with  a  string  message,  UPA  names  the  last  cell  of  an 
array  into  which  an  alphabetic  character  was  stored, 
counting  from  the  top  of  some  one-dimensional  array. 
UPA  is  decremented  by  1  each  time  an  available  cell 
needs  to  be  named,  requires  read  access  to  UPA,  A 
names  a  one-dimensional  array,  which  from  UPA  to  its 
upper  bound  contains  alphabetic  characters,  requires 
read  access  for  A,  assumes  read  access  to  CHAR,  CHAR 
contains  the  next  unstored  character  from  the 
alphabet  or  generics  being  currently  processed, 
requires  read  access  to  AL,  AL[1]  ...  AL[NA]  names 
the  index  of  the  lower  bound  of  fhe  characters  in  an 
alphabet,  i.e.  AL[i]  is  the  lower  bound  for  the 
i-th  alphabet  and  AL[i-l]  is  the  upper  bound  for 
that  alphabet,  where  AL[0]  equals  the  initial  value 
plus  1  of  UPA 

:  1 8:  TESTAL  l.E. 

ior  K  ♦-  UPA  slop  1  until  AL[NA]  -  1  do 
if  CHAR  *=  A[K]  then 

ERRORfCHARACTER  APPEARS  TWICE  IN  ALPHABET"); 

effects  and 
post-conditions. 

CHAR  has  not  occurred  already  id  the  alphabet  being 
processed 
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(s) 

1  Is 
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1)  requires  the  ability  to  invoke  :3:,  ERROR,  with  a  string  message 

2)  requires  ability  to  invoke  NEXTCARD  which  makes  a  new  card  image 
available,  i.e.  ability  to  invoke  :2:  and  returns  to  the  invoker 

only  if  a  card  for  the  current  algorithm  is  available 

3)  NEXTCHAR  is  the  value  of  the  character  which  immediately 
follows  the  character  of  the  current  card  image  produced  by 
the  last  call  of  NEXTCHAR 

4)  an  end-of-file  condition  has  occurred 

5)  requires  the  ability  to  invoke  the  termination  of  the  entire 

program,  i.e.  :  1 .5:  ENDOFFILE 

6)  requires  the  ability  to  invoke,  AlGINiT  (:1.1.1 :) 

the  start  of  processing  for  a  new  algorithm 

7)  CP  is  an  index  into  C  and  indexes  the  last  character  which 

was  produced  as  a  value  from  NEXTCHAR.  After  an  execution 
of  NEXTCARD,  :2:,  CP  must  equal  0 

8)  write  access  required  for  CP 

9)  C[l]  ...  C[80]  contains  the  characters, 

in  order,  of  the  card  image  which  is  inputted  as  a  result 
of  the  last  execution  of  GETIMAGE 

10)  requires  read  access  to  C 

11)  requres  ability  to  invoke  GETIMAGE  which  inputs  a  card 
and  returns  to  the  caller  only  if  a  card  was  inputted 

12)  in  columns  1  and  2  indicate  that  the  program  is  to  terminate 
and  a  in  column  1  only  indicates  that  a  new  algorithm 

is  to  be  processed 

13)  requires  ability  to  print  the  string  argument  which  is  passed  as 

the  parameter  to  ERROR 

14)  ability  to  perform  printing  operations 

15)  requires  aDility  to  invoke  :1.4:  which  processes  the  remaining 
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data  images  for  this  algorithm 

16)  requires  write  access  to  PR 

17)  pr  =  true  means  "print  the  register  after  each  successful 
application  of  a  rule;  otherwise  d  not  print  the  register 
after  each  successful  application  of  a  rule 

18)  MAXA  equals  the  maximum  number  of  alphabets  permitted  for 

an  algorithm 

19)  requires  read  access  to  MAXA 

20)  ability  to  set  the  failure  routine  for  NEXTCHAR,  i.e.  FAIL 

can  be  assigned  a  name  which  can  be  invoked  if  no  more  characters 
are  available  from  IMEXTCHAR 

21)  NG  contai  ns  the  number  of  generic  variables  encountjred 
for  the  current  algorithm 

22)  CG[i],  1  <  i  <  NG,  equals  the  i-th  generic  variable 
encountered  for  the  current  algorithm 

23)  AG[i],  i  <  i  <  NG,  equals  the  alphabet  name  which 
CG[i]  is  a  generic  variable 

24)  a  failure  routine  has  been  set  if  NEXTCHAR  cannot 
provide  additional  characters  from  the  current  image 

25)  read  access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN,  CLOSE  which 
contain  the  values  of  .  ,  ,  ,  :  ,  ;  ,  1  ,  ) 

26)  assumes  write  access  to  CHAR 

27)  assumes  read  access  to  CHAR 

28)  requires  ability  to  invoke  RULES  which  names  the  rule  input 
part,  but  since  RULES  is  a  label  in  the  main  program 

a  go  to  statement  can  be  used 

29)  ERRHEAD  assumes  compete  control  when  invoked 

and  handles  error  messages  and  further  processing 

30)  NA  equals  the  number  of  alphabets  which  have  been  processed 

thus  far  for  the  current  algorithm 

31)  requires  read  accesss  to  NA 

32)  requires  write  access  to  NA 

33)  requires  read/write  access  to  NOIT,  which  controls  a 
loop  that  process  alphabets 

34)  requires  ability  to  invoke  STORALPH,  which  stores  the  alphabet 
character  u  all  requirements  are  met.otnerwise  STORALPH 
invokes  appropriate  error  routines 

35)  requires  read/write  access  to  NOiTl,  which  controls  a  loop 

that  processes  generics 

36)  requires  ability  to  invoke  STORGEN  which  stores  the  content 

of  CHAP,  if  legal,  otherwise  invokes  the  apporpriate 
error 

37)  requires  ability  to  invoke  ALPHFIN  which  cmpletes  any 
needed  processing  after  an  entire  alphabet  has  been 
stored 

38)  either  no  alphabets  have  been  processed  of  all  alphabets 
processed  have  been  correct 

39)  requires  ability  to  invoke  FAIL  which  correctly  determines 
which  objects  assume  control 

40)  read  access  required  for  CP 
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41)  read  and  write  access  required  for  the  variable  1 

42)  requires  ability  to  invoke  TESTLEGAL  which  returns  only  if 

CHAR  is  not  7, 

43)  requires  ability  to  invoke  TESTGEN  which  returns  only  if 

CHAR  is  not  equal  to  an  already 
used  generic  variable  for  this  algorithm 

44)  A  names  a  one-dimensional  array,  which  from  UPA  to  its 
upper  bound  contains  alphabetic  characters 

45)  requires  read  access  for  A 

46)  NG  contains  the  number  of  generic  variables  encountered 
for  the  current  algorithm 

47)  requires  read  access  to  NG 

48)  requires  write  access  to  NG 

49)  requires  write  access  to  AG 

50)  CHAR  contains  the  next  unstored  character 

from  the  alphabet  or  generics  being  currently  processed 

51)  AL[1]  ...  AL[NA]  names  the  index  of  the  lower  bound  of  the 
characters  in  an  alphabet,  i.e.  AL[i]  is  the  lower 

bound  for  the  i-th  alphabet  and  AL[i-lj  is  the 
upper  bound  for  that  aiphabet,  where  AL[0]  equals  the 
initial  value  plus  1  of  UPA 

52)  requires  read  access  to  AL 

53)  requires  ability  to  invoke  ERRGEN,  which  assumes 
control  and  invokes  an  appropriate  error  routine 

54)  requires  ability  to  invoke  TESTAL  which  returns  only  if 

CHAR  is  not  equal  to  a  character  which  has  already  occurred  in  the 
alphabet  currently  being  pro, ^ssed 

55)  requires  ability  to  invoke  TEST  which  returns  only  if  there 
storage  space  as  indicated  by  the  values  of  LPA  and  UPA 

56)  UPA  names  the  last  cell  of  an  array  into  which  an  alphabetic 
character  was  stored,  counting  from  the  top  of  some 
one-dimensional  array.  UPA  is  decremented  by  1 

each  time  an  available  cell  needs  to  be  named 

57)  requires  read  access  to  UPA 

58)  requires  wnie  access  to  UPA 

59)  A  names  a  one-dimensional  array,  which  from  UPA  to  its 
upper  bound  contains  alphabetic  characters 

60)  requires  write  access  for  A 

61)  requires  write  access  to  AL 

62)  LPA  names  the  las  cell  of  an  array  into  which  rules 
are  stored  counting  from  the  lower  bound  of  a 
one-dirr.ensional  array  .  LPA  is  incremented  by  one  each 
time  an  available  cell  needs  to  be  named 

63)  requires  read  access  to  LPA 

64)  LPA  and  UPA  are  ndex  variables  for  the  same  array 

65)  requires  read  access  to  CG 

66)  requires  write  access  to  CG 

67)  requires  read/write  access  to  J 

68)  requires  read/write  access  to  K 

69)  requires  read  access  tor  A 
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After  examining  entropy  loading  values  for  these  new  objects,  the 
following  good  decomposition  was  found 

((a)  «r)  ((•)  ((f)  «s)  ((I)  (  (  k  ,  o  )  ((i) 

((d,g,h)((v,w)  ((x)  ((c)  ((  y  ,  u  )  ((  2  ,  t) 

(  m  ,  q  ,  p  ))  1.66  )  1.48  )  1.44  )  1.44  )  1.31  ) 

1.00  )  1.02  )  .47  )  .41  )  .55  )  .36  )  .10  )  .12  )  0 
This  decomposition  is  similar  to  the  decomposition  at  the  last  stage. 
Because  objects  (r)  ...  (v)  were  introduced,  the  generic  and  alphabet 

input  parts  interact  strongly  with  the  rest  of  the  program. 
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Next,  :1 .3:  that  inputs  rules,  is  elaborated.  A  map  for  this 
elaboration,  as  well  as  a  map  for  several  objects  invoked  by  the 
elaboration  of  :1.3:,  appears  below. 

(*a)  :  1.3.1:  (236)  set  failure  routine  to  ERRULENAME. 

/ 

/  (#b)  :  1.3.2:  (236)  initialize  for  rule  input. 

(*c)  :1.3.3:  (236)  get  a  new  input  card. 

:1.3:  ' - (*d)  :  1.3.4:  (237)  as  long  as  the  input  card  is  a  rule,  keep 

executing  :1.3.5:  and  :1.3.6:. 

(*e)  :  1 .3.5:  print  card;  input  and  store  rule. 

(*f)  :1.3.6:  (237)  get  a  new  input  card. 

(*g)  :1.3.7:  (238)  process  end  of  rules  conditions. 


(*h)  :  1.3.5. 1:  (238)  print  card 
(*i)  :1.3.5.2:  (238)  initialize  for  new  rule. 
(*j)  :1.3.5.3:  (238)  process  rule  label. 

:  1.3.5:  —  (*k)  :1.3.5.4:  (239)  collect  left  part  of  rule. 


(*l)  :1.3.5.5:  (239)  initialize  for  right  part. 

(*m)  :1.3.5.6:  (240)  collect  and  store  right  part. 

(*n)  :1.3.5.7:  (241)  collect  and  store  successor  label. 


(*o)  :20:  (242)  input  a  label. 

(*p)  :21:  (243)  store  a  label. 

(*q)  :30:  (244)  mark  rule  as  a  terminal  rule. 

(*r)  :3 1:  (245)  process  successor  part  of  rule. 
(#s)  :32:  (246)  make  a  character  part  of  this  rule. 
(*t)  :33:  (247)  initialize  for  rule  processing. 
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(*u)  :34:  (248)  initialize  for  processing  a  new  rule. 

(#v)  :35:  (249)  initialize  for  processing  right  part  of  rule. 

(#w)  :36:  (250)  process  end  of  all  rule  input  conditions. 

(#x)  :37:  (250)  check  whether  the  current  card  should  be 
interpreted  as  a  rule. 

(*a)  :  1.3. 1 : 

assumptions:  requires  ability  to  set  the  failure  routine  for 

NEXTCHAR,  i.e.  the  ability  to  invoke  SETFA1L  with  a 
variable  which  names  the  part  which  is  to  be  invoked 
if  no  more  characters  are  available  from  NEXTCHAR, 
ERRULENAME  contains  the  value  which  indicates  a 
routine  which  can  take  control  if  an  error  is 
discovered  as  rules  are  being  stored,  requires  read 
access  to  ERRULENAME 

-.1.3.1:  SETFAIL(ERRULENAME); 

effects  and 

post-conditions:  failure  routine  for  NEXTCHAR  has  been  set  to  the 

part  named  by  ERRULENAME 

(*b)  :  1 .3.2 : 

assumptions:  requires  ability  to  invoke  INITRA,  which 

initializes  the  input  part  for  rules  for  a  new 
algorithm 

-.1.3.2:  EXECUTE  ANY  NEEDED  IN'  .“1AL1ZATI0NS  FOR 
INPUTTING  THE  RULES  FOR  AN  ALGORITHM,  l.E.  INITRA; 

effects  and 

post-conditions:  rule  input  part  can  correctly  accept  a  set  of  rules 

for  a  new  algorithm 

(*c)  :  1.3.3: 

assumptions:  requires  ability  to  invoke  NEXTCARD  which  makes  a 

new  card  image  available,  i.e.  ability  to  invoke 
:2:  and  returns  to  the  invoker  only  if  a  card  for 
the  current  algorithm  is  available 

:  1.3.3:  NEXTCARD; 

effects  and 

post-conditions:  a  new  card  image  has  been  read  and  is  available 
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(*d)  :1.3.4: 

assumptions:  requires  ability  to  invoke  CARDISRULE  which 

determines  whether  the  current  card  image  is  to  be 
interpreted  as  as  a  rule  or  not 

:1.3.4: 

while  CARDISRULE  do 
begin 
:  1.3.5:  ; 

:  1 .3.6: 

end; 

effects  and 

post-conditions:  all  rules  for  this  algorithm  have  been  successfully 

inputted 

(*e)  :1.3.5: 

assumptions:  requires  ability  to  invoke  PRINTCARD  which  prints 

the  current  card  image, 

:  1.3.5:  PRINTCARD; 

INPUT  AND  STORE  A  RULE; 

effects  and 

post-conditions:  card  image  has  been  printed  and  a  single  rule  has 

been  correctly  inputted 

(*f)  :1.3.6: 

assumptions:  requires  ability  to  invoke  NEXTCARD  which  makes  a 

new  card  image  available,  i.e.  ability  to  invoke 
:2:  and  returns  to  ihe  invoker  only  if  a  card  for 
the  current  algorithm  is  available 

:1.3.6:  NEXTCARD; 

effects  and 

post-conditions:  a  new  card  image  has  been  inputted  and  is  available 
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<*g)  :  1.3.7 : 
assumptions: 

offsets  and 
post-conditions: 

(*h)  :1. 3.5.1: 
assumptions: 

effects  and 
post-conditions: 

(*i)  :1.3.5.2: 

assumptions: 

effects  and 
post-conditions: 

(*j)  :1. 3.5.3: 

assumptions: 


effects  and 
post-conditions: 


requires  ability  to  invoke  EDR,  end  of  rules 
condition  processor 

-.1.3.7:  EDRj 


all  end-of  -rule  conditions  have  been  correctly 
resolved 

Next,  -.1.3.5:,  which  inputs  a  single  rule,  is 

elaborated. 


requires  ability  to  invoke  PRINTCARD  which  prints 
the  current  card  image 

:  1.3.5. 1:  PRINTCARD; 


current  card  image  has  been  printed 


requires  ability  to  invoke  INITR  which  initializes 
for  inputting  a  new  rule 

-.1.3.5. 2:  INITIALIZE  FOR  THIS  RULE  I.E.  INITR; 


rule  input  is  properly  initialized  to  accept  a  new 
rule 


requires  ability  to  invoke  LABL  which  collects  a 
label  terminated  by  the  character  in  TERM  and  leaves 
the  integer  label  value  in  LAB,  requires  ability  to 
invoke  STORLABEL  which  associates  the  label  with  the 
current  rule,  requires  write  access  to  TERM,  read 
access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN,  CLOSE  which 
contain  the  values  of  V,  ")" 

:  1.3.5.3:  TERM  ♦-  COLON; 

LABL; 

STORLABEL; 


label  of  current  rule  has  been  correctly  processed 
and  associated  with  the  current  rule 
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(*K)  :1.3.5.4: 

assumptions:  NEXTCHAR  is  the  value  of  the  character  which 

immediately  follows  the  character  of  the  current 
card  image  produced  by  the  last  call  of  NEXTCHAR,  a 
failure  routine  has  been  set  if  NEXTCHAR  cannot 
provide  additional  characters  from  the  current 

image,  read  access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN, 
CLOSE  which  contain  the  values  of 

assumes  write  access  to  CHAR, 
requires  ability  to  invoke  TESTLEGAL  which  returns 
only  if  CHAR  is  not  ability  to 

invoke  STORCHAR  which  returns  only  if  the  content  of 
CHAR  could  be  successfully  stored  with  rule  being 
processed 

:1. 3.5.4:  COLLECT  AND  STORE  LEFT  PART  OF  RULE,  I.E. 

CHAR  «-  NEXTCHAR; 
while  CHAR  /  COLON  do 
begin 

TESTLEGAL; 

STORCHAR; 

CHAR  «-  NEXTCHAR 

end; 

effects  and 

post-conditions:  the  left  part  of  a  rule  has  been  correctly  stored 

(#1)  :1. 3.5.5: 

assumptions:  requires  ability  to  invoke  IN1TRIGHT  which 

initializes  for  processing  the  input  of  a  right  part 
of  a  ruie 

:1. 3.5.5:  INITIALIZE  FOR  RIGHT  HALF  RULE  PROCESSING 
I.E.  INITRIGHT 

effects  and 

post-conditions:  the  right  half  of  the  rule  can  be  correctly 

processed 
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(*m)  :  1 .3.5.6: 

assumptions: 


NEXTCHAR  is  the  value  of  the  character  which 
immediately  follows  the  character  of  the  current 
card  image  produced  by  the  last  call  of  NEXTCHAR,  a 
failure  routine  has  been  set  if  NEXTCHAR  cannot 

provide  additional  characters  from  the  current 
image,  assumes  write  access  to  CHAR,  assumes  read 
access  to  CHAR,  requires  ability  to  invoke  TESTLEGAL 
which  returns  only  if  CHAR  is  not  ">"> 

M:",  read  access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN, 
CLOSE  which  contain  the  va  ues  of  H,M, 

T,  ")“,  ability  to  invoke  STORCHAR  which 
returns  only  if  the  content  of  CHAR  could  be 

successfully  stored  with  rule  being  processed 

:1. 3.5.6:  COLLECT  AND  STORE  RIGHT  HALF  OF  RULE  I.E. 

CHAR  -  NEXTCHAR; 

while  CHAR  t  DOT  a  CHAR  t  SEMI  a  CHAR  i  COMMA  do 
begin 

TESTLEGAL; 

STORCHAR; 

CHAR  4-  NEXTCHAR 
end; 


effects  and 
post-conditions: 


right  half  of  the  rule  has  been  correctly  processed 
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(*n)  :1. 3.5.7: 
assumptions: 


effects  and 
post-conditions: 


read  access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN,  CLOSE 
which  contain  the  values  of  .  ,  ,  ,  :  ,  ;  >  v  , 
")",  requires  the  ability  to  invoke  :3:,  ERROR,  with 
a  string  message,  which  does  not  return  but  handles 
further  processing,  assumes  read  access  to  CHAR,  a 
failure  routine  has  been  set  if  NEXTCHAR  cannot 

provide  additional  characters  from  the  current 
image,  assumes  write  access  to  CHAR,  NEXTCHAR  is  the 
value  of  the  character  which  immediately  follows  the 
character  of  the  current  card  image  produced  by  the 
last  call  of  NEXTCHAR,  requires  ability  to  invoke 
PROCTERM  which  indicates  a  rule  as  a  terminal  rule; 
requires  ability  to  invoke  PROCSUC  which  processes 
the  successor  part  of  a  rule,  requires  read  access 
to  LAB,  requires  write  access  to  TERM,  requires 
ability  to  invoke  LABL  which  collects  a  label 

terminated  by  the  character  in  TERM  and  leaves  the 
integer  label  value  in  LAB,  a  negative  value  in  LAB 
indicates  that  no  label  was  collected 

;1.3.5.7:  COLLECT  AND  PROCESS  SUCCESSOR  PART  OF 
RULE,  I.E. 

if  CHAR  ft  SEMI  then 
begin 

if  CHAR  -  DOT  then 

begin 

PROCTERM; 

CHAR  v-  NEXTCHAR; 

if  CHAR  ■/  StMI  then 

EKRORfRULE  NOT  CORRECT”) 

end 

else 

if  CHAR  =  COMMA  then 
begin 

TERM  «-  SEMI; 

LABL; 

if  LAB  <  0  then 

ERRORfSUCCESSOR  MISSING") 

PROCSUC; 

end; 

end; 


the  successor  part  of  the  current  rule  has  been 
correctly  processed 
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(*o)  :20: 
assumptions: 


•(facts  and 
post-conditions: 


Below  are  the  elaborations  of  the  additional 
functions  which  are  needed. 


a  failure  routine  has  been  set  if  NEXTCHAR  cannot 
provide  additional  characters  from  the  current 

image,  TERM  contains  the  non-digit  character  which 
is  expected  to  terminate  a  label,  requires  read 
access  to  TERM,  assumes  write  access  to  CHAR, 
assumes  read  access  to  CHAR,  NEXTCHAR  is  the  value 
of  the  character  which  immediately  follows  the 
character  of  the  current  card  image  produced  by  the 
last  call  of  NEXTCHAR,  the  digits  "0",  "1",  "2",  ... 
,  "9"  are  represented  by  character  codes  such  that 
"0"  -  ZERO  =  0,  ...  ,”9"  -  ZERO  =  9  and  the  only 
legal  label  characters  are  digits  and  BLANK, 

read/write  access  to  LAB  is  required,  legal  range  of 
labels  is  1  through  100,  BLANK  contains  the 

representation  of  a  space  and  ZERO  contains  the 
representation  of  a  zero,  requires  read  access  to 
BLANK  and  ZERO  ,  requires  the  ability  to  invoke  :3:, 
ERROR,  with  a  string  message,  which  does  not  return 
but  handles  further  processing 

:20:  LABL,  l.E. 

LAB  4-  -1; 

CHAR  ♦-  NEXTCHAR; 
while  CHAR  /  TERM  do 

begin 

if  CHAR  >  7ER0  a  CHAR  <  ZERO  +  9  then 
LAB  «-  (if  LAB  >  0  then  10  *  LAB  +  CHAR  -  ZERO 
else  CHAR  -  ZERO) 

else 

if  CHAR  /  BLANK  then 
ERRORCILLEGAL  CHARACTER  IN  LABEL”); 

CHAR  ♦-  NEXTCHAR 
end; 

if  LAB  =  0  or  LAB  >  100  then 

ERRORCLABEL  OUT  OF  RANGE”); 

return  the  value  of  LAB; 


a  syntactically  correct  label  has  been 
concatenated,  if  control  returns  to  caller;  if  no 
label  has  been  concatenated,  the  value  -1  is 
returned 
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(*p)  :21: 

assumptions: 


affects  and 
post-conditions: 


assumes  LAB  contains  a  legal  label  name  or  -1  which 
indicates  that  no  label  has  been  concatenated, 
requires  read  access  to  LAB,  requires  write  access 
to  LAB,  N1  names  the  rule  being  currently  inputted, 
requires  read  access  to  Nl,  requires  ihe  ability  to 
invoke  :3:,  ERROR,  with  a  string  message,  which  does 

not  return  but  handles  further  processing,  R  names  a 

one-dimensional  array  which  contains  pointers  to 
rules  such  that  label  i  names  rule  R[i];  R[i]  =  0 
means  label  i  is  not  defined;  R[i]  >  0  means  the 

label  is  defined  and  R[i]  is  a  pointer  to  the  rule 
it  namws;  R[i]  <  0  means  that  label  i  is  undefined 

but  has  been  referenced  by  rule  -R[i]  and  is  the 

head  of  a  chain,  A  names  a  one-dimensional  array 
which  from  its  lower  bound  to  LPA  contains 
representations  of  rules,  requires  write  access  for 
A,  after  rule  initialization,  A[N1]  -  1  =  NR,  Nl 
names  the  current  rule  A[N1]  =  -1,  N2  =  Nl  +  1,  A[N2] 

=  2,  NE  =  Nl  +  2  and  the  location  which  is  the  name 

of  the  immediately  preceding  rule  names  the  current 
rule.  thus  if  NT  is  the  value  of  Nl  prior  to  this 

initialization  then  A[N1’]  =  Nl  -  unless  NR  =  1  in 
which  case  the  previous  value  of  Nl  is  not  defined 

:21:  STORLABEL 

if  LAB  >  0  then 
begin 

if  R[LAB]  >  0  then  ERRORf'DOUBLE  LABEL 
OCCURRENCE"); 

if  R[LAB]  =■  0  then  R[LAB]  <-  Nl 
else 

while  R[LAB]  <  U  do 
begin 

TEMP  «-  -  R[LAB]; 

R[LAB]  ♦-  A[TEMP]j 
A[TEMP]  <-  Nl 
end; 
end; 


label  LAB  has  been  stored  and  all  undefined 
references  to  LAB  have  been  resolved 
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(*q)  :30: 

assumptions:  after  rule  initialization,  A[N1]  -  1  =  NR,  N1  names 

the  current  rule  A[N1]  ■  -1,  N2  =  Nl  +  1,  A[N2]  ■  2, 

NE  *■  Nl  +  2  and  the  location  which  is  the  name  of 

the  immediately  preceding  rule  names  the  current 
rule.  thus  if  Nl’  is  the  value  of  N1  prior  to  this 
initialization  then  A[N1’]  =  Nl  -  unless  NR  =  1  in 

which  case  the  previous  value  of  Nl  is  not  defined, 

requires  read  access  to  N2,  requires  write  access 
for  A,  A  names  a  one-dimensional  array  which  from 
its  lower  bound  to  LPA  contains  representations  of 
rules,  a  value  of  -1  in  A[N2]  indicates  that  the 
rule  is  a  terminal  rule 


:30:  PROCTERM,  l.E. 

A[N2]  *-  -1; 

•(facts  and 

postconditions:  the  rule  is  marked  as  terminal 
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(*r)  :31: 
assumptions: 


offsets  and 
post-conditions: 


after  rule  initialization,  A[N1]  -  1  =  NR,  N1  names 
the  current  rule  A[N1]  =  -1,  N2  ■  Nl  +  1,  A[N2]  =  2, 
NE  =  N1  +  2  and  the  location  which  is  the  name  of 
the  immediately  preceding  rule  names  the  current 
rule.  thus  if  NT  is  the  value  of  N1  prior  to  this 
initialization  then  A[N1’]  =  N1  -  unless  NR  «  1  in 

which  case  the  previous  value  of  N1  is  not  defined, 

R  names  a  one-dimensional  array  which  contains 
pointers  to  rules  such  that  label  i  names  rule  R[i]; 

R[i]  -  0  means  label  i  is  not  defined;  R[i]  >  0 

means  the  label  is  defined  and  R[i]  is  a  pointer  to 
the  rule  it  namws;  R[i]  <  0  means  that  label  i  is 
undefined  but  has  been  referenced  by  rule  -R[i]  and 
is  the  head  of  a  chain,  requires  write  access  to  R, 
requires  read  access  to  R,  A  names  a  one-dimensional 
array  which  from  its  lower  bound  '.o  LPA  contains 
representations  of  rules,  requires  write  access  for 
A,  assumes  LAB  contains  a  legal  label  name  or  -1 
which  indicates  that  no  label  has  been  concatenated, 
requires  read  access  to  N2,  requires  read  access  to 
LAB 

:31:  PROCSUC,  I.E. 

if  R[LAB]  >  0  then  A[N2]  <-  R[LAB] 

else 

if  R[IAB]  -  0  .hen 

begin 

R[LaB]  «-  -N2; 

A[N2]  «-  0 

end 

else 

begin 

A[N2]  «-  R[LAB]; 

R[LAB]  ♦-  -N2 

end; 


the  successor  to  the  current  rule  has  been  set  or 
made  part  of  a  chain  of  rules  which  have  the  same, 
yet  undefined,  successor 
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(*c)  :32: 
assumptions: 


•(facts  and 
post-conditions; 


requires  read  access  to  NE,  NE  names  a  cell  in  A 
such  that  A[NE]  indicates  the  current  number  of 
characters  in  the  rule  part  being  processed  -  left 
part  if  the  left  part  is  being  processed  or  right 
part  if  the  right  part  is  being  processed,  assumes 
read  access  to  CHAR,  NG  contains  the  number  of 
generic  variables  encountered  for  the  current 
algorithm,  requires  read  access  to  NG,  CG[i],  1  £  i 
<  NG,  equals  the  i-th  generic  variable  encountered 
for  the  current  algorithm,  requires  read  access  to 
CG,  LPA  names  the  las  cell  of  an  array  into  which 
rules  are  stored,  counting  from  the  lower  bound  of  a 
one-dimensional  array  .  LPA  is  incremented  by  one 
each  time  an  available  cell  needs  to  be  named, 
requires  read  accesss  to  NA,  requires  write  access 
to  LPA,  requires  ability  to  invoke  TEST  which 
returns  only  if  there  storage  space  as  indicated  by 
the  values  of  LPA  and  UPA,  requires  read/write 
access  to  L,  A  names  a  one-dimensional  array  which 
from  its  lower  bound  to  LPA  contains  representations 
of  rules,  requires  write  access  for  A 

:32:  STORCHAR  I.E. 

L  -  1: 

while  I  <  NG  a  CG[L]  t  CHAR  do 
L  «-  L  +  1; 

LPA  ♦-  LPA  +  1; 

TEST; 

if  L  >  NG  then 
A[LPA]  ♦-  CHAR 

else 

A[LPA]  ♦-  -  L; 

A[NE]  ♦-  A[NE]  +  1; 


A[LPA]  is  negative  if  CHAR  was  a  generic  and 
-A[LPA]  then  indexes  the  generic  in  CG;  otherwise 
A[l.PA]  IS  CHAR  A[NE]  contains  tne  number  of 
characters  encountered  thus  far  for  the  rule  part 
being  processed 
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(*t)  :33: 
assumptions: 


effects  and 
post-conditions: 


at  most  100  labels  are  permitted  and  their 
definitions  appear  in  the  one-dimensional  arra/ 
R[  1:1 00]  such  that  R[i]  contains  the  definition  of 
label  i  when  the  label  is  interpreted  as  a  positive 
integer,  R  names  a  one-dimensional  array  which 
contains  pointers  to  rules  such  that  label  i  names 
rule  R[i];  R[i]  “  0  means  label  i  is  not  defined; 
R[i]  >  0  means  the  label  is  defined  and  R[i]  is  a 
pointer  to  the  rule  it  namws;  R[i]  <  0  means  that 
label  i  is  undefined  but  has  been  referenced  by  rule 
-R[i]  and  is  the  head  of  a  chain,  requires  write 
access  to  R,  NR  indicates  the  rulename  which  is 
currently  being  processed  requires  write  access  to 
NR, 

:33:  1N1TRA  l.E. 

NR  «-  0; 

SETFAIL(ERRULENAME); 

for  H  <-  1  step  i  until  100  do  R[H]  «-  0; 


the  error  routine  for  NEXTCHAR  is  set  to  ERRULE  and 
all  iabel  definitions  are  set  to  0,  i.e.  undefined 
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(*u)  :34: 
assumptions: 


•(facts  and 
post-conditions: 


NR  indicates  the  rulename  which  is  currently  being 

processed,  requires  write  access  to  NR,  LPA  names 
the  las  cell  of  an  array  into  which  rules  are 
stored,  counting  from  the  lower  bound  of  a 
one-dimensional  array  .  LPA  is  incremented  by  one 
each  time  an  available  cell  needs  to  be  named, 
requires  read  accesss  to  NA,  requires  write  access 
to  LPA,  requires  ability  to  invoke  TEST  which 

returns  only  if  there  storage  space  as  indicated  by 
the  values  of  LPA  and  UPA,  A  names  a  one-dimensional 
array  which  from  its  lower  bound  to  LPA  contains 
representations  of  rules,  after  rule  initialization, 

A[N1]  -  1  «  NR,  N1  names  the  current  rule  A[N1]  « 

-1,  N2  -  Nl  +  1,  A[N2]  -  2,  NE  -  Nl  +2  and  the 

location  which  is  the  name  of  the  immediately 
preceding  rule  names  the  current  rule.  thus  if  Nl’ 
is  the  value  of  Nl  prior  to  this  initialization  then 
A[N1’]  =  Nl  -  unless  NR  ■=  1  in  which  case  the 
previous  value  of  Nl  is  not  defined,  requires  read 
access  to  N2,  requires  write  access  to  N2,  NE  names 

a  cell  in  A  such  that  A[NE]  indicates  the  current 
number  of  characters  in  the  rule  part  being 
processed  -  left  part  if  the  left  part  is  being 
processed  or  right  part  if  the  right  part  is  being 

processed,  requires  read  access  to  NE,  requires 

write  access  to  NE 

:34:  INITR  -  initialize  for  new  rule  i.e. 

NR  ♦-  NR  +  1; 

LPA  ♦-  LPA  +  4; 

TEST; 

A[LPA  -  3]  <-  NR; 

if  NR  >  1  then  A[N1]  «-  LPA  -  2; 

Nl  ♦-  LPA  -  2; 

A[N1]  ♦-  -1; 

N2  ♦-  LPA  -  1; 

A[N2]  ♦-  2; 

NE  ♦-  LPA; 

A[NE]  ♦-  0; 


after  rule  initialization,  A[N1]  -  1  *>  NR,  Nl  names 
the  current  rule  A[N1]  =■  -1,  N2  =•  Nl  +  1,  A[N2]  =  2, 

NE  =  Nl  +  2  and  the  location  which  is  the  name  of 

the  immediately  preceding  rule  names  the  current 
rule.  thus  if  NT  is  the  value  of  Nl  prior  to  this 

initialization  then  A[N1’]  °  Nl  -  unless  NR  =  1  in 

which  case  the  previous  value  of  Nl  is  not  defined 
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(*v)  :35: 
assumptions: 


effects  and 
post-conditions: 


after  rule  initialization,  A[N1]  -  1  =  NR,  N1  names 
the  current  rule  A[N1]  =  -1,  N2  =  Nl  +  1,  A[N2]  =  2, 

NE  ■  N1  +  2  and  the  location  which  is  the  name  of 

the  immediately  preceding  rule  names  the  current 
rule.  thus  if  Nl’  is  the  value  of  N1  prior  to  this 

initialization  then  A[N1’]  ■  Nl  -  unless  NR  =  1  in 
which  case  the  previous  value  of  Nl  s  not  defined, 

LPA  names  the  las  cell  of  an  array  into  wHch  rules 

are  stored,  counting  from  the  lower  bound  of  a 

one-dimensional  array  .  LPA  is  incremented  by  one 

each  time  an  available  cell  needs  to  be  named, 

requires  read  accesss  to  NA,  requires  write  access 
to  LPA,  requires  ability  to  invoke  TEST  which 
returns  only  if  there  storage  space  as  indicated  by 

the  values  of  LPA  and  UPA,  NE  names  a  cell  in  A  such 
that  A[NE]  indicates  the  current  number  of 

characters  in  the  rule  part  being  processed  -  left 
part  if  the  left  part  is  being  processed  or  right 

part  if  the  right  part  is  being  processed,  requires 

read  access  to  NE,  requires  write  access  to  NE 

:35:  INITRIGHT  l.E. 

LPA  «-  LPA  +  i; 

TEST; 

NE  -  LPA; 

A[NE]  «-  0; 


A[NE]  “  0  and  indicates  the  current  number  of 
characters  in  trie  right  half  of  the  current  rule 
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(*w)  :36: 
assumptions: 


effects  and 
post-conditions: 

<*x)  :37: 
assumptions: 


effects  and 
post-conditions: 


R  names  a  one-dimensional  array  which  contains 
pointers  to  rules  such  that  label  i  names  rule  R[i]; 
R[i]  <=  0  means  label  i  is  not  defined;  R[i]  >  0 
means  the  label  is  defined  and  R[i]  is  a  pointer  to 
the  rule  it  namws;  R[i]  <  0  means  that  label  i  is 
undefined  but  has  been  referenced  by  rule  ~R[i]  and 
is  the  head  of  a  chain,  requires  read  access  to  R, 
NR  indicates  the  rulename  which  is  currently  being 
processed,  requires  read  access  to  NR,  requires  the 
ability  to  invoke  :3:,  ERROR,  with  a  string  message, 
which  does  not  return  but  handles  further 
processing,  requires  read/write  access  to  Q  :36:  EDR 
I.E. 

for  Q  <-  1  step  1  until  100  do 

if  R[Q]  <  0  then  ERRORfUNDEFINED  LABEL(S)"); 

if  NR  <  0  then  ERRORC'ALGORITHM  CONTAINS  NO  RULES"); 


a  set  of  rules  has  successfully  been  inputted  and 
constitutes  a  syntactically  correct  algorithm 


read  access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN,  CLOSE 
which  contain  the  values  of  "("> 

")",  C[l]  ...  C[80]  contains  the  characters,  in 

order,  of  the  card  image  which  is  inputted  as  a 
result  of  the  last  execution  of  GETIMAGE,  requires 
read  access  to  C,  a  colon  in  column  A  when 
processing  rules  indicates  that  the  card  is  to  be 
interpreted  as  a  rule 


:37:  CARDISRULE  I.E. 


C[4J  =  COLON 


true  if  card  is  to  be  interpreted  as  a  rule;  false 
otherwise 
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(*x)  537:  1 

1)  requires  the  ability  to  invoke  :3:,  ERROS,  with  a  string  message, 

which  does  not  return  but  handles  further  processing 

2)  requires  ability  to  invoke  NEXTCARD  which  makes  a  new  card  image 
available,  i.e  ability  to  invoke  :2:  and  returns  to  the  invoker 

only  if  a  card  for  the  current  algorithm  is  ava  table 

3)  NEXTCHAR  is  the  value  of  the  character  which  immediately 
follows  the  character  of  the  current  card  image  produced  by 
the  last  call  of  NEXTCHAR 

4)  an  end-of-file  condition  has  occurred 

5)  requires  the  ability  to  invoke  the  termination  of  the  entire 

program,  i.e.  :  1 .5:  END0FF1LE 

6)  requires  the  ability  to  invoke,  ALGINIT  (:  1 . 1 . 1 :) 

the  start  of  processing  for  a  new  algorithm 

7)  CP  is  an  index  into  C  and  indexes  the  last  character  which 

was  produced  as  a  value  from  NEXTCHAR.  After  an  execution 
of  NEXTCARD,  :2:,  CP  must  equal  0 

8)  write  access  required  for  CP 

9)  C[l]  ...  C[80]  contains  the  characters, 

in  order,  of  the  card  image  which  is  inputted  as  a  result 
of  the  last  execution  of  GETiMAGE 

10)  requires  read  access  to  C 

11)  requires  ability  to  invoke  GETIMAGE  which  inputs  a  card 
and  returns  to  the  caller  only  if  a  card  was  inputted 

12)  in  columns  1  and  2  indicate  that  the  program  is  to  terminate 
and  a  in  column  1  only  indicates  that  a  new  algorithm 

is  to  be  processed 

13)  requires  ability  to  print  the  string  argument  which  is  passed  as 

the  parameter  to  ERROR 

14)  ability  to  perform  printing  operations 

15)  requires  ability  to  invoke  :  1 .4:  which  processes  the  rema;ning 

data  images  for  this  algorithm 

16)  requires  write  access  to  PR 

17)  pr  «=  true  means  "print  the  register  after  each  successful 
application  of  a  rule;  otherwise  d  not  print  the  register 
after  each  successful  application  of  a  rule 

18)  MAXA  equals  the  maximum  number  of  alphabets  permitted  for 

an  algorithm 

19)  requires  read  access  to  MAXA 

20)  requires  ability  to  set  the  failure  routine  for  NEXTCHAR,  i.e. 
the  ability  to  invoke  SETFA1L  with  a  variable  which  names 
the  part  which  is  to  be  invoked  if  no  more  characters  are 
available  from  NEXTCHAR 

21)  NG  contains  the  number  of  generic  variables  encountered 
for  the  current  algorithm 

22)  CG[i],  1  <  1  <  NG,  equals  the  i-th  generic  variable 
encountered  for  the  current  algorithm 

23)  AG[i],  1  <  i  <  NG,  equals  the  alphabet  name  which 
CG[i]  is  a  generic  variable 
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24)  a  failure  routine  has  been  set  if  NEXTCHAR  cannot 
provide  additional  characters  from  the  current  image 

25)  read  access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN,  CLOSE  which 

contain  the  values  of  ,’)" 

26)  assumes  write  access  to  CHAR 

27)  assumes  read  access  to  CHAR 

28)  requires  ability  to  invoke  RULES  whicn  names  the  rule  input 
part,  but  since  RULES  is  a  label  in  the  main  program 

a  go  io  statement  can  be  used 

29)  ERRiiEAQ  assumes  compete  control  when  invoked 

and  handies  error  message;  and  further  processing 

30)  IMA  equals  the  number  of  alphabets  which  have  been  processed 

thus  far  for  the  current  algorithm 

31)  requires  read  accesss  to  NA 

32)  requires  write  access  to  NA 

33)  requres  read/write  access  to  NOIT,  which  controls  a 
loop  that  process  alphabets 

34)  requires  ability  to  invoke  STORALPH,  which  stores  the  alphabet 
character  .f  all  requirements  are  met, otherwise  STORALPH 
invoke*.,  appropriate  error  routines 

35)  requires  read/write  access  to  N01T 1 ,  which  controls  a  loop 

that  processes  generics 

36)  require  ,  ability  to  invoke  STORGEN  which  stores  the  content 

of  CHAR,  if  legal,  otherwise  invokes  the  apporpriate 

errei 

37)  requires  ability  to  invoke  ALPHFIN  which  cmpletes  any 
needed  processing  after  an  entire  alphabet  has  been 
stored 

38)  either  no  alphabets  have  been  processed  rf  all  alphabets 
processed  have  been  correct 

39)  requires  abihty  to  invoke  FAIL  winch  correctly  determines 
which  objects  assume  control 

40)  read  access  required  for  CP 

41)  read  and  write  access  required  tor  the  variable  1 

42)  requires  ability  to  invoke  TESTLEGAL  which  returns  only  If 

CHAR  is  not  'V, 

43)  requires  ability  to  invoke  TESTGcN  which  returns  only  if 

CHAR  is  not  equal  to  an  already 
used  generic  variable  for  this  algorithm 

44)  A  names  a  one-dimensional  array,  which  from  UPA  to  its 
upper  bound  contains  alphabetic  characters 

45)  requires  read  access  for  A 

46)  NG  contains  the  number  of  generic  variables  encountered 
for  the  current  algorithm 

47)  requires  read  acces*.  to  NG 

48)  requires  wme  access  io  NG 

49)  requires  wnie  access  io  AG 

50)  CHAR  contains  the  next  unstored  character 

from  the  alphabet  or  generics  being  currently  processed 

51)  AL[1]  ...  Al[NA]  names  the  index  of  the  lower  bound  of  the 
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characters  in  an  alphabet,  i.e.  AL[i]  is  the  lower 
bound  for  the  i-th  alphabet  and  AL[i-l]  is  the 
upper  bcand  for  that  alphabet,  where  AL[0]  equals  the 
initial  value  plus  1  of  UPA 

52)  requires  read  access  to  AL 

53)  requires  ability  to  invoke  ERRGEN,  which  assumes 
control  and  invokes  an  appropriate  error  routine 

54)  requires  ability  to  invoke  TESTAL  which  returns  only  if 

CHAR  is  not  equal  to  a  character  which  has  a!roarl/  occurred  in  the 
alphabet  currently  being  processed 

55)  requires  ability  to  invoke  TEST  which  telum^  only  if  there 
storage  space  as  indicated  by  the  values  of  LPA  and  UPA 

56)  l 'PA  names  the  last  cell  of  an  array  into  which  an  alphabetic 
character  was  stored,  counting  from  the  iop  of  some 
one-dimensional  array.  UPA  is  decremented  by  1 

each  time  an  available  cell  needs  to  be  named 

57)  requires  read  access  to  UPA 

58)  requires  write  access  to  UPA 

59)  A  names  a  one-dimensional  array,  which  from  UPA  to  its 
upper  bound  contains  alphabetic  characters 

60)  requires  write  access  for  A 

61)  requires  write  access  to  AL 

62)  LPA  names  the  las  cell  of  an  array  into  which  rules 
are  stored,  counting  from  the  lower  bound  of  a 
one-dimensional  array  .  LPA  is  incremented  by  one  each 
time  an  available  cell  needs  to  be  named 

63)  requires  read  access  to  LPA 

64)  LPA  and  UPA  are  index  variables  for  the  same  array 

65)  requires  read  access  to  CG 

66)  requires  write  access  to  CG 

67)  requires  read/wriie  access  to  J 

68)  requires  read/write  access  to  K 

69)  requires  read  access  for  A 

70)  requires  ability  to  invoke  lfJifRA,  which  initializes  the 

input  part  tor  rules  for  a  new  aigoritnm 

71)  requires  aoility  to  invoke  CARU1SRULE  wtvcn  determines 

whether  the  current  card  image  is  to  be  interpreted  as 

as  a  rule  or  not 

72)  requires  ability  to  invoke  PR1NTCARD 

which  prints  the  current  card  image 

73)  requires  ability  to  invoke  EDR,  end  of  rules  condition 

processor 

74)  requires  ability  to  invoke  iNITR  which  initializes 

for  inputting  a  new  rule 

75)  requires  ability  to  invoke  LABL  which  collects  a  label 

terminated  by  the  character  in  TERM  and  leaves  the  integer 

label  value  in  LAB 

76)  requires  ability  to  invoke  STORLABEL  which  associates 

the  label  with  the  current  rule 

>7)  requires  write  access  to  TERM 
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78)  ability  to  invoke  STORCHAR  which  returns  only  if  the 

content  of  CHAR  could  be  successfully  stored  with  rule 
being  processed 

79)  requires  'ibility  to  invoke  IN1TRIGHT  which  initializes 

for  processing  the  input  of  a  right  part  of  a  rule 

80)  requires  ability  to  invoke  PROCTERM  which  indicates  a  rule  as 

a  terminal  rule;  requires  ability  to  invoke  PROCSUC 
which  processes  the  successor  part  of  a  rule 

81)  requires  read  access  to  LAB 

82)  a  negative  value  in  LAB  indicates  that  no  label  was  collected 

83)  after  rule  initialization,  A[N1]  -  1  =  NR,  N1  names  the 

current  rule  A[N1]  =  -1,  N2  =  Nl  +  1,  A[N2]  °  2,  NE  ■  N1  +2 

and  the  location  which  is  the  name  of  the 

immediately  preceding  rule  names  the  current  rule,  thus  if 

NT  is  the  value  of  N1  prior  to  this  initialization 

then  A^NT]  <=  N 1  -  unless  NR  »  1  in  which  case  the  previous 

value  of  N1  is  not  defined 

84)  R  names  a  one-dimensionai  array 

which  contains  pointers  to  rules  such  that  label  i 
names  rule  R[i]; 

R[i]  =  0  means  label  i  is  not  defined; 

R[i]  >  0  means  the  label  is  defined  and  • 

R[i]  is  a  pointer  to  the  rule  it  namws; 

R[i]  <  0  means  that  label  i  is  undefined  but  has 
been  referenced  by  rule  -R[i]  and  is 
the  head  of  a  chain 

85)  requires  write  access  to  R 

86)  requires  read  access  to  R 

87)  A  names  a  one-dimensional  array  which  from  its 

lower  bound  to  LPA  contains  representations  of  rules 

88)  requires  read  access  to  NE 

89)  NE  names  a  cell  in  A  such  tiiat  A[NEJ  indicates  the  current  number 

of  characters  in  the  rule  part  being  processed  -  left  part 
if  the  left  part  is  being  processed  or  right  part  if  the 
right  part  is  being  processed 

90)  requires  write  access  to  LPA 

91)  at  most  100  labels  are  permitted  and  their  definitions 

appear  in  the  one-dimensional  array  R[  1 : 1 00}  such  that 
R[i]  contains  the  definition  of  label  i  when  the  label 
is  interpreted  as  a  positive  integer 

92)  NR  indicates  the  rulename  which  is  currently 

being  processed 

93)  requires  read  access  to  NR 

94)  requires  write  access  to  NR 

95)  requires  write  access  to  NE 

96)  TERM  contains  the  non-digit  character  which  is  expected 
to  terminate  a  label 

97)  requires  read  access  to  TERM 

98)  the  digits  ”0",  "1",  "2",  ...  ,  "9"  are  represented  by  character 

codes  such  that  "0"  -  ZERO  ■  0,  ...  ,"9"  -  ZERO  =  9 
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and  the  only  legal  label  characters  are  digits  and  BLANK 

99)  read/write  access  to  LAB  is  required 

100)  legal  range  of  labels  is  1  through  100 

101)  BLANK  contains  the  representation  of  a  space  and  ZERO 
contains  the  representation  of  a  zero 

102)  requires  read  access  to  BLANK  and  ZERO 

104)  assumes  LAB  contains  a  legal  label  name  or  -1  which 
indicates  that  no  label  has  been  concatenated 

105)  requires  write  access  to  LAB 

106)  Nl  names  the  rule  being  currently  inputted 

107)  requires  read  access  to  Nl 

108)  ERRULENAME  contains  the  value  which  indicates  a  routine 
which  can  take  control  if  an  error  is  discovered  as  rules 
are  being  stored 

109)  requires  read  accejS  to  ERRULENAME 
1  10)  requires  read  access  to  N2 

111)  requires  read/write  access  to  L 

112)  requires  write  access  to  N2 

113)  a  colon  in  column  4  when  processing  rules  indicates  that 
the  card  is  to  be  interpreted  as  a  rule 

114)  requires  read/write  access  to  Q 

115)  a  value  of  -1  in  A[N2]  indicates  that  the 
rule  is  a  terminal  rule 

116)  ERRHtADNAME  is  a  variable  which  names  the  routine  ERRHEAD 

117)  requires  read  access  to  ERRHEADNAME 

1  18)  RULESNAME  is  a  variable  which  names  the  routine  RULES  which 
inputs  the  rules  for  an  algorithm 
119)  requires  read  access  to  RULESNAME 
RUB  for  the  expansion  of  :  1 .3:  is 

«a)  «r)  ((e)  «*)  ds)  ((I)  (  (  k  ,  o  )  <(i) 

((  d  ,  g  ,  h  )  (  (  v  ,  w  ;((  x)  \(c)  ((  y  ,  u  )  ((  z  ,  t  ) 

(  m  ,  q  ,  p  ))  1.73  )  1.28  )  l  55  )  i.50  )  1.39  )  1.11  ) 

1.12  )  .39  )  .35  )  47  )  .30  )  .08  )  .10  )  0 

The  actual  loadings  are 

((a)  ((r)  ((e)  ((♦)  ((s)  (0)  (  (  k  ,  o  )  ui) 

((  d  ,  g  ,  h  )  (  (  v  ,  w  )  ((  x) 

((  ,  *b  ,  *c  ,  *d  ,  *e  ,  *f  ,  *g  )  ((  y  ,  u  )  ((  z  ,  t  ) 

(  m  ,  q  ,  p  ))  1.29  )  1.28  )  .83  )  1.16  )  1.02  )  96  )  .98  )  54  ) 


u5  )  .47  )  .M  )  07  )  10  )  0 
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These  va  ues  are  mostly  lower  than  the  RUB  for  the  expansion. 
Consequently,  no  attempt  will  be  made  to  find  a  better  decomposition  for 
this  stage. 

RUB  for  the  expansion  of  :1.3.5:  is 

((a)  «r)  ((•)  ((f)  «s)  ((I)  <  (  k  ,  o  )  «i) 

«  d  ,  g  ,  h  )  (  (  v  ,  w  )  ((  x) 

((  *a  ,  *b  ,  *c  ,  *d  ,  #e  ,  *f  ,  *g  )  ((  y  ,  u  )  ((  z  ,  t  ) 

(  m  ,  q  ,  p  ))  1.03  )  1.06  )  .83  )  .91  )  .65  )  .87  )  .88  )  .48 

.31  )  .42  )  .26  )  .08  )  .09  )  0 

Unfortunately,  the  actual  loadings  are 

((a)  ((r)  ((e)  ((f)  ((s)  (0)  (  (  K  ,  o  )  «i) 

((  d  ,  g  ,  h  )  (  (  v  ,  w  )  ((  x) 

((  *a  ,  *b  ,  *c  ,  *d  ,  *h  ,  *i  ,  *j  ,  *k  ,  *1  , 

*m  ,  *n  ,  *f  ,  *g  )  ((  y  ,  u  )  ((  z  ,  t  ) 

(  m  ,  q  ,  p  ))  1.29  )  1.28  )  .83  )  1.16  )  1.02  )  .96  )  .98  )  .54  ) 

.35  )  .47  )  .30  )  .07  )  .10 

A  modification  of  this  decomposition  leads  to  the  following  better 
decomposition 

((a)  ((r)  ((•)  ((f)  <(s)  ((I)  (  (  k  ,  o  )  ((i> 

((  d  ,  g  ,  b  )  (  (  v  ,  w  )  ((  x) 

((  #a  ,  *b  ,  *c  ,  *d  ,  #b  ,  *i  ,  *j  ,  *1  , 

*f  ,  *g  )  «  y  .  U  )  «  z  ,  t  ) 

(  m  ,  q  ,  p  ,  *k  ,  *m  ,  *n  ))  1.57  )  1.41  )  1.39  )  1.36  ) 

.97  )  1.00  )  1.01  )  .47  )  .49  )  .60  )  .26  )  .07  )  .09  )  0 
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Here,  those  objects  that  recognize  and  store  information  for  the  rule 
execution  part  (  m  ,  q  ,  #K  ,  #m  ,  #n  )  interact  most  with  the  rest  of 
the  program.  Also,  those  objects  that  control  and  invoke  the  above 
mentioned  objects  share  much  information  and  appear  grouped  together  ( 
*a  ,  *b,  *c  ,  *d  ,  *h  ,  *i  ,  *j  ,  *1  ,  *g  ,  *f  ).  Since  the  remaining 
objects  in  the  table  will  be  used  -  in  part  -  by  the  expansion  o(  :1.4:, 
an  analysis  of  the  entropy  loadings  involving  them  is  postponed  until 
after  the  elaboration  of 
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Below  is  a  map  of  the  elaboration  of  :1.4:  and  most  of  the  remaining 
objects. 

(>a)  :  1.4. 1 :  (262)  control  input  of  the  initial  register 

/contents  and  markov  algorithm  execution. 


I  (>b)  :1.4.2s  (262)  print  card;  input  initial  register 

/  contents. 


/  (>c)  :  1.4.3. 1 :  (263)  initialize  for  execution  of  currently 

stored  algorithm  and  the  current  register  contents. 

/// 

j  /  (>d)  :  1 .4.3.2:  (264)  control  attempts  to  apply  the  rules. 

//// 

/  (>e)  :  1 .4.3.3 :  (264)  attempt  to  apply  current  rule. 

/  "  r 
'  / 

:1.4:  -  (>f)  :  1 .4.3.4:  (265)  rpplace  matched  string  and  possibly  print 

the  register  contents;  set  next  rule  to  the  successor  for  a 

successful  application  of  the  current  rule. 

(>g)  :  1 .4.3.5:  (265)  set  next  rule  to  be  the  successor  for  a 

failure  to  match  left  part  of  current  rule. 

Oh)  :  1 .4.3  6:  (266)  terminate  algorithm  interpretation  if 

necessary. 


(>i)  :40:  (267)  search  for  an  instance  of  the  left  half  of  a 

rule  in  the  register. 

(>j)  :41:  (269)  replace  matcned  string  by  the  right  half  of 

the  current  rule. 

(>k)  :42:  (270)  adjust  the  register  to  accomodate  the  right 
half  of  the  current  rule. 

01)  :43:  (271)  insert  the  right  half  of  the  current  rule  into 
the  register. 

(>m)  :44:  (272)  test  whether  a  generic  variable  matches  a 
character  in  the  register. 

On)  :45:  (272)  test  whether  a  rule  character  is  a  generic. 

(>0)  :46:  (273)  get  a  character  from  t fie  left  part  of  a  rule. 

Op)  :47:  (273)  get  the  successor  for  a  rule  that  corresponds 

to  a  successful  application  of  the  rule. 

(>q)  :48:  (273 1  get  the  successor  for  a  rule  that  corresponds 

to  an  unsucces  ful  application  of  the  rule. 
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(>r)  :49:  (274)  get  the  location  of  the  first  character  of  the 
left  part  of  the  current  rule. 

(>s)  :50:  (274)  indicate  an  error  in  the  heading  for  an 
algorithm. 

(>t)  :51:  (275)  invoke  the  rule  input  part  of  the  program. 

(>u)  ;52:  (274)  indicate  an  error  in  a  rule. 

(>v)  :53:  (275)  indicate  an  error  in  an  initial  register  data 

image 

(>w)  :54:  (275)  indicate  a  generic  variable  occurring  in  the 
data. 

(>x)  :55:  (275)  initialize1  all  generic  variables  to  be 

undefined. 

(>y)  :65:  (276)  get  character  from  the  right  part  of  the 

current  rule. 

(>z)  :66:  (276)  test  whether  a  generic  variable  is  defined. 

(<a)  :67 :  (276)  get  the  length  of  the  right  part  of  the 

current  rule. 

(<b)  :68:  (277)  get  the  character  associaled  with  a  generic 
variable. 

(<c)  :70:  (277)  get  the  length  of  the  left  part  of  the  current 
ruie. 
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Below  is  an 
respect  to  its 

(>a)  :  1.4.1: 

assumptions: 


(>b)  :1.4.2: 
assumptions: 


elaboration  of  :1.4:,  which  executes  an  algorithm  with 
data  images 


assumes  all  rules  have  been  inputted  correctly; 
assumes  that  the  current  card  isrepresents  an 
initial  register  contents;  assumes  that  NEXTCARD 
returns  control  only  if  a  data  image  is  available 
for  the  current  algorithm 

:  1.4. 1 :  repeat 
begin 
:1.4.2:  ; 

:  1 .4.3:  ; 

:1.4.4: 

end 

until  fatse; 


requires  the  ability  to  invoke  :4:,  ERRORE,  with  a 
string  message,  which  does  not  return  but  handles 
further  processing  at  the  execution  stage,  requires 
ability  to  invoke  PRINTCARD  which  prints  the  current 
card  image,  ERRDATANAME  contains  a  value  which 

indicates  a  routine  which  indicates  a  routine  which 

can  take  control  if  an  error  is  discovered  while  an 
initial  register  contents  is  being  input,  requires 

read  access  to  ERRDATANAME,  requires  ability  to  set 

the  failure  routine  for  NEXTCHAR,  i.e.  the  ability 

to  invoke  SETFAIL  with  a  variable  which  names  the 
part  which  is  to  be  invoked  if  no  more  characters 
are  available  from  NEXTCHAR,  REG,  is  a 

one-dimensional  array  which  comains  the  characters 
in  the  register,  assumes  write  access  to  REG, 
assumes  read  access  to  MAXRL  winch  contains  the 
maximum  number  of  characters  permitted  in  the 
register,  NEXTCHAR  is  the  value  of  the  character 
which  immediately  follows  the  character  of  the 

current  card  image  produced  by  the  last  call  of 

NEXTCHAR,  requires  ability  to  invoke  TESTLEGAL  which 
returns  only  if  CHAR  is  not  .  ,  ,  »  »  >  •  » 

requires  ability  to  invoke  TESTGEN  which  returns 
only  if  CHAR  is  not  equal  to  an  already  used  generic 
variable  for  this  algorithm,  requires  write  access 
to  RL,  requires  read/write  access  to  RPP  which  is 
used  as  a  temporary  register  position  pointer  when 
the  register  is  being  innally  filled,  requires 

read/write  access  to  RC  which  is  used  to  contain 
single  characters  from  the  current  data  card  when 
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affects  and 
post-conditions: 

(>c)  :  1.43.1: 
assumptions: 


affects  and 
post-conditions: 


the  register  is  being  filled,  read  access  to  DOT, 
COMMA,  COLON,  SEMI,  OPEN,  CLOSE  which  contain  the 
values  of  M,H,  V,  T 

:  1 .4.2:  PR1NTCARD;  INPUT  THE  INITIAL  REGISTER 
CONTENTS,  I.E 

PRINTCARD; 

SETFAIL(ERRDATANAME); 

RPP  «-  0; 

RC  «-  NEXTCHARj 
while  RC  P  SEMI  do 
begin 

RPP  «-  RPP  +  lj 
if  RPP  >  MAXRL  then 

ERRORECREGISTER  OVERFLOW"); 

TESTLEGAL; 

TESTGEN; 

REG[RPP]  4-  RC; 

RC  «-  NEXTCHAR; 
end; 


RL  4-  RPP; 


an  initial  register  contents  has  been  correctly  set 
into  the  register  and  RL  contains  the  numbei  of 
characters  in  the  register 

the  name  of  the  first  rule  is  2,  MAXT1  contains  the 
number  of  trial  rule  applications  still  permitted 
for  this  execution  of  an  algorithm,  requires  write 
access  to  MAXT1,  write  access  to  RULENAME  required, 
RULENAME  names  the  rule  currently  being  processed 

:  1.43.1:  INITIALIZE  PROCESSING  FOR  CURRENT 

ALGORITHM  WITH  CURRENT  REGISTER  CONTENTS,  I.E. 

RULENAME  «-  2; 

MAXT1  4-  MAXT; 


processing  initialized  for  current  algori’.hm  and 
register  contents 
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(>d)  :1.4.3.2: 

assumptions:  RULENAME  names  the  rule  currently  being  processed, 

requires  read  access  to  TRM,  FIN  is  a  result  of 
NOSUC  which  indicates  that  there  are  no  more  rules 
which  can  be  applied,  requires  read  access  to  FIN, 
read  access  to  RULENAME  required,  TRM  is  a  result  of 
SUCSUC  and  UNSUCSUC  which  indicates  that  the 
algorithm  should  terminate,  i.e.  TERM  names  no 
legal  and  indicates  termination 

:1. 4.3.2:  while  RULENAME  /  TERM  A  RULENAME  t  FIN  do 

begin 

:1.4.3.3:  ; 

:1.4.3.4:  ; 

:1.4.3.5:  ; 

:  1 .4.3.6:  ; 
end: 

effects  and 

post-conditions:  ;  n  algorithm  has  been  executed  with  respect  to  an 

initial  register  contents 

(>e)  :  1 .4.3.3 : 

assumptions:  requires  ability  to  invoke  SEARCH  which  searches 

for  a  match  Of  the  left  part  of  rule  RULENAME,  and 
which  returns  the  value  true  if  a  match  is  found, 
false  otherwise,  requires  the  ability  to  invoke  :4:, 

ERRORE,  with  a  string  message,  which  does  not  return 
but  handles  further  processing  at  the  execution 
stage,  MAXT1  contains  the  number  of  trial  rule 
applications  still  permitted  for  this  execution  of 
an  algorithm,  requires  read  access  to  MAXT1, 
requires  write  access  to  MAXT1 

: 1 .4.3.3: 

MAXT1  ♦-  MAXTi  -  1; 

if  MAXTI  <  0  ther,  ERROREfMAXIMUM  NUM3ER  OF  TRIALS  EXCEEDED"); 
if  SEARCH  then 

:1  4.3.4:  else  :1.4.3.5:  ; 

effects  and 

post-conditions:  the  rule,  RULENAME,  has  been  applied,  if  possible, 

to  the  register  contents  and  a  new  successor  rule 
has  been  set  in  RULENAME 
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Of)  :1A3A 

assumptions: 


effects  and 
post-cmditions: 


Of)  :1A3.5: 
assumptions: 


effects  and 
post-condi  ions: 


RULENAME  names  the  rule  currently  being  processed, 
requires  ability  to  invoke  REPLACE,  which  has  the 
•»ffect  of  replacing  the  register  contents  with  the 
right  part  of  the  rule  named  by  RULENAME,  where  the 
left  part  was  matched,  requires  the  ability  to 
invoke  SUCSUC  which  has  the  value  of  the  success  to 
rule  RULENAME  for  a  successful  application  of  rule 
RULENAME,  write  access  to  RULENAME  required, 
requ'res  read  access  to  PR,  pr  =  true  means  "pr:nt 
the  register  after  each  successful  application  of  a 
rule;  otherwise  d  not  print  the  register  after  each 
successful  application  of  a  rule,  requires  the 
ability  to  invoke  PR1NTREG  which  prints  the  contents 
of  the  register 

:1A3A  REPLACE; 

RULENAME  «-  SUCSUC; 

if  PR  then  PRINTREG; 


the  right  part  of  rule,  RULENAME,  has  replaced  the 
left-most  occurrence  of  the  left  part  of  the  rule, 
RULENAME 


RULENAME  names  the  rule  currently  being  processed, 
requires  the  ability  to  invoKe  IINSUCSUC  which  has 
the  value  of  the  name  of  the  successof  to  rule 
RULENAME  after  an  unsuccessful  application  of  rule 
RULENAME,  write  access  to  RULENAME  required, 

:1  A3.5:  RULENAME  <-  UNSUCSUC; 


RULENAME  contains  the  name  of  the  rule  which  is  to 
be  attempted  next  if  the  current  rule  could  not  be 
applied  successfully 
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(>h)  :1. 4.3.6: 
assumptions: 


effects  and 
post-conditions: 


RULENmME  names  the  rule  currently  being  processed, 
requires  the  ability  to  invoke  :4:,  ERRORE,  with  a 
string  message,  which  does  not  return  but  handles 
further  processing  at  the  execution  stage,  requires 
the  ability  to  invoke  PRINTREG  which  prints  the 
contents  of  the  register,  pr  =  true  "vans  "print  the 
register  after  each  successful  application  of  a 
rule;  otherwise  d  not  print  the  register  after  each 
successful  application  of  a  rule,  requires  read 
access  to  PR,  if  RULENAME  =  TRM  then  dot  termination 
has  occurred,  otherwise  the  rules  have  been 
exhausted,  read  access  to  RULENAME  required,  TRM  is 
a  result  of  SUCSUC  and  UNSUCSUC  which  indicates  that 
the  algorithm  should  terminate,  i.e.  TERM  names  no 
legal  and  indicates  termination 

:1. 4.3.6:  if  RULENAME  =  TRM  then 
begin 

it  NOT(PR)  then 

PRINTREG; 

ERROREC'DOT  TERMINATION") 
end 
else 

ERROREC'RULES  EXHAUSTED"); 

The  appropriate  termination  message  has  been 
printed  and  ERRORE  has  been  invoked  to  handle 
further  processing 


APPENDIX  I:  A  MARKOV  ALGORITHM  PROCESSOR 


267 


(>i)  :40: 

assumptions:  requires  the  ability  to  invoke  LEFT  which  names  the 

location  which  is  the  first  character  of  the  left 
part  of  rule,  RULENAME,  requires  ability  to  invoke 
LEIMGTHL  which  has  the  value  of  the  number  of 

characters  in  the  left  part  of  the  rule  named  by  its 
parameter,  RULENAME  names  the  rule  currently  being 

processed,  reaa  access  to  RULENAME  required,  LEN 
names  the  number  of  the  character  in  the  left  Dart 
of  the  rule  currently  being  processed,  requires  read 
access  to  LEN,  requires  write  access  to  LEN,  LFT 
names  the  starting  location  for  the  left  part  of  the 
current  rule  name,  requires  read  access  to  LFT, 
requires  write  access  to  LFT,  requires  read/write 

access  to  NOSUC,  RL  contains  the  current  register 
length,  requires  read  access  to  RL,  requires  ability 

to  invoke  RULLFTCHR(A.B)  which  produces  the  value  of 
the  B-th  character  of  the  left  part  which  starts  at 
A,  and  requires  ability  to  invoke  IN1TGEN  which  sets 

the  definitions  of  all  generic  variables  to  be 
undefined,  RP  names  the  character  position  where  a 

character  sequence  is  to  be  replaced,  requires  read 
access  to  RP,  requires  write  access  to  RP,  requires 
ability  to  invoke  GENERIC  which  has  the  value  true 

if  its  parameter  represents  a  generic  variable, 
requires  read/write  access  to  CC,  requires 
read/write  access  to  LHP,  REG,  is  a  one-dimensional 

array  which  contains  the  characters  in  the  register, 
assumes  read  access  to  REG 

:40:  SEARCH  I  E. 

LFT  -  LEFT(RULENAI.'E); 

LEN  <-  LENGTHURULENAME); 

NOSUC  «-  true; 
if  RL  >  LEN  then 
begin 
RP  -  0; 

while  RP  <  RL  ♦  1  -  1  EN  a  NOSUC  do 
begin 

RP  ♦-  RP  ♦  1 
LHP  «-  lj 
NOSUC  -  false; 

INI!  GEN; 

while  LHP  <  LEN  a  NOT(NOSUC)  do 

begin 

CC  •-  RULLFTCHR(LCT,  LHP); 
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if  GENERiC(CC)  then 
begin 

if  NOT(MATCHGEN(CC,  RlG[RP  +  LHP  -  1]  )  then 
NOSUC  true 
end 

else 

if  CC  +  REG[RP  +  LHP  -  1]  then 
NOSUC  «-  true 
LHP  «-  LHP  ♦  1 
end; 

end; 

end; 

SEARCH  -  NOT(NOSUC); 

i  ifects  and 

postconditions:  SEARCH  *»t'ue  if  the  left  part  of  rule  RULENAMI- 

matches  a  substring  of  the  register  and  sets  up 
internal  variables  whicn  can  be  used  by  REPLACE  for 
replacing  the  first  occurrence  of  a  match  from  the 
left  end  of  the  register  by  the  right  part  of  rule 
RULENAME;  false  otherwise 


- - 
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Oj>  :41: 

assumptions:  requires  ability  to  invoke  LENGTHL  which  has  the 

value  of  the  number  of  characters  in  the  left  part 
of  the  rule  named  by  its  parameter,  requires  the 
ability  to  invoke  :4:,  ERRORE,  with  a  string 
message,  which  does  not  return  but  handles  further 
processing  at  the  execution  stage,  requires  ability 
to  invoke  ADJUST  whose  first  parameter  indicates  the 
number  of  characters  in  the  left  part  of  a  rule  and 
whose  second  par  imeter  indicates  the  number  of 
characters  in  the  right  part  of  the  rule.  ADJUST 
modifies  the  register,  if  necessary,  so  that  the 
right  part  can  be  inserted  where  the  matched  left 
part  is,  requires  ability  to  invoke  INSERT  which 
inserts  the  appropriate  right  part  over  the  matched 
Ipft  part,  requires  ability  to  invoke  LENGTHR  which 
returns  the  value  of  the  number  of  characters  in  the 
right  part  of  the  rule  named  by  its  parameter, 
requires  recd/wnte  access  to  LF.N  and  LENR,  requires 
read  access  to  LENR,  requires  write  access  to  LENR 

:41:  REPLACE  I.  E. 

LENR  -  LENGTHRiRULENAME); 

LENL  -  LENGTHL(RULENAME); 
if  RL  -  LENL  ♦  LENR  >  MAXRL  then 
ERROREfREGISTER  OVERFLOW")! 

ADJUST(LENL,LENR); 

INSERT; 

effects  and 

post-conditions:  the  right  part  of  rule,  RULENAME,  lias  replaced  the 

leftmost  occurrence  of  the  left  part  of  RULEMAME 
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(>k)  :42: 
assumptions: 


RL  contains  the  current  register  length,  requires 
read  access  to  RL.  requires  write  access  to  RL, 
requires  read  access  to  LI,  L2,  and  TP;  LI  contains 
the  length  of  a  -.hcrader  sequence  being  replaced  by 
a  character  sequence  of  length  L2,  REG,  is  a 
one-dimensional  array  which  contains  the  characters 
in  the  register,  assumes  read  access  to  REG,  assumes 
write  access  to  REG,  RP  names  the  character  position 
where  a  character  sequence  is  to  be  replaced, 
requires  read  access  to  RP,  assumes  LI  H  L2 

•42:  ADJUSTCL1.L2);  I.E. 

if  LI  <  L2  then 
begin 

for  TP  -  RL  step  -1  until  RP  ♦  LI  do 
REG[TP  L2  -LI]*-  REG[TP]; 
end 

else 

begin 

for  TP  «-  RP  +  LI  step  1  until  RL  do 
REG[TP  +  L2  -  LI]  <-  REG[TP]; 

end; 

RL  ♦-  RL  +  N2  -  Nl; 


the  register  is  modified  so  that  a  replacement  of  a 
string  starting  at  RP  of  length  LI  can  take  place 
correctly  >or  a  string  of  length  L2 


effects  and 
post-conditions: 
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01)  :43: 
assumptions: 


effects  and 
post-conditions: 


requires  read  write  access  to  TQ  and  CQ,  RP  names 
the  character  position  where  a  character  sequence  is 
to  be  replaced,  requires  read  access  to  RP,  requires 
ability  to  invoke  GENERIC  which  has  the  value  tru* 
if  its  parameter  represents  a  generic  variable, 

requires  ability  to  invoke  RULRTCHAR(A)  which 
returns  the  character  which  is  the  A-th  character  of 
the  right  side  of  rule  RULENAME,  requires  the 
ability  to  invoke  UNOEF(A)  which  returns  the  value 
tru«  if  A  is  an  undefineu  generic  variable 

representation  for  this  rule  application;  falsa 
otherwise,  requires  ability  to  invoke  VALG(A)  which 
produces  the  character  associated  with  the  generic 
representation  A  for  this  rule  application,  requires 
the  ability  to  invoke  ERRORE,  with  a  string 

message,  which  does  not  return  but  handles  further 
processing  at  the  execution  stage,  REG,  is  a 
one-dimensional  array  which  contains  the  characters 
in  the  register,  assumes  write  access  to  REG, 

assumes  LENR  contains  the  length  of  the  string  being 
inserted,  requires  read  access  to  LENR 


:43:  INSERT  l.E. 

for  TQ  1  step  1  until  LENR  do 
begin 

CO  -  RULRTCHAR(TQ); 
if  GENERIC(LO)  then 
bogin 

if  UNDERGO)  then 

ERRORLf "UNDEFINED  GENERIC  USED  IN  RIGHT  PART  OF  RULE") 
else  REGtRP  ♦  TQ  -  1]  *-  VALG(CQ) 
end 

else 

REG[RP  ♦  TO  -  1]  «-  CO 

end; 


the  characters  in  the  right  part  of  a  rule  have 
been  stored  into  successive  locations  of  REG 
starting  at  RP 
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Om)  :44: 

assumptions:  AL[  1  ]  ...  AL[NA]  names  the  index  of  the  lower 

bound  of  the  characters  in  an  alphabet,  i.e.  AL[i] 
is  the  lower  bound  for  the  i-th  alphabet  and  AL[i-l] 
is  the  upper  bound  for  that  alphabet,  where  AL[0] 
equals  the  initial  value  plus  1  of  UPA,  requires 

read  access  to  AL,  AG[i],  1  <  i  <  NG,  equals  the 
alphabet  name  which  CG[i]  is  a  generic  variable, 
requires  read  access  to  AG,  G  is  a  one-dimensional 
array  such  that  G[i]  ■  -1  if  generic  variable  i  is 

not  defined  after  a  successful  search  for  a  left 
part  of  a  rulei,  otherwise  G[i]  >  0  and  is  the 
character  corresponding  to  the  generic  i,  requires 
read  access  to  G,  requires  write  access  to  G, 

requires  read/write  access  to  NMAT 

:44:  MATCHGEN'CC.Q)  I.E.  NMAT  ♦-  true;  if  Gr-CC]  <  0 
then  begin  T  <-  AL[AG[-CC]];  while  NMAT  a  T  < 

AL[AG[-CC]  -1]  do  begin  if  Q  ■  A[T]  then  begin 
G[-CC]  ♦-  A[T];  NMAT  f-  false  end;  end  else  if  G[-CC] 
■  Q  then  NMAT  *-  false 

MATCHGEN  <-  NOT  (NMAT); 

effects  and 

postconditions:  MATCHGEN  =  true  if  the  generic  indicated  by  CC  is 

matched  by  Q;  false  otherwise 

On)  :45: 

assumptions:  assumes  that  a  generic  in  a  rule  has  been  saved  as 

a  negative  value 

:45:  GENERIC(S)  I.E. 

GENERIC  ♦-  S  <  0; 

effects  and 

post-conditions:  GENERIC  =  true  if  S  represents  a  generic  variable; 

false  otherwise 

Oo)  :46: 

requires  read  access  for  A,  assumes  Q  is  a  legal 
character  pointer  into  the  left 


assumptions: 
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:46:  RULLFTCHR(P,Q)  I  E. 

RULCHAR  ♦-  A[P  +  Q  ♦  2]; 

effects  and 

post-conditions:  RULLFTCHR  ■  the  Q-th  character  in  the  left  part  of 

the  rule  named  by  P 

Op)  :47: 

assumptions:  requires  read  access  <or  A,  assumes  A[RULENAME  +  1] 

names  the  successor  for  rule  RULENAME  for  a 
successful  application  of  rule  RULENAME,  RULENAME 
names  the  rule  currently  being  processed,  read 
access  to  RULENAME  required, 


:47:  SUCSUC  «-  AfRULLNAME  +  1]  j 


offsets  and 

post-conditions:  SUCSUC  names  the  rule  to  be  tried  next  after  a 

successful  application  of  rule,  RULENAME 

Oq)  :48: 

assumptions:  requires  read  access  for  A,  RULENAME  names  the  rule 

currently  being  processed,  read  access  to  RULENAME 
required,  assumes  A[RULENAME]  names  the  successor 
rule  for  rule  RULENAME  after  an  unsuccessful 
application  of  rule  RULENAME 


:48:  UNSUCSUC  -  A[RULENAME]; 


effects  and 

post-conditions:  UNSUCSUC  names  the  rule  to  be  tned  next  after  an 

unsuccessful  application  fo  rule  RULENAME 
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Or)  :49: 

assumptions:  assumes  X  +  2  is  an  index  which  names  the  first 

character  of  the  left  part  of  a  rule  -1 

:49:  LEFT(X)  I.E. 

LEFT  «-  X  ♦  2; 


•ffacts  and 

post-conditions:  LEFT  is  a  value  which  names  the  left  part  of  rule  X 

Os)  :50: 

assumption::  requires  the  ability  to  invoke  :3:,  ERROR,  with  a 

string  message,  which  does  not  return  but  handles 
further  processing 

:50:  ERRHEAD,  I.E. 

ERRORCHEADING  NOT  CORRECT”): 


•ffacts  and 

post-conditions:  :3:,  ERROR,  has  been  invoked  and  handles  all 

further  processing 

00  :51: 

assumptions:  requires  ability  to  invoke  RULES  which  names  the 

rule  input  part,  but  since  RULES  is  a  label  in  the 
main  program  a  go  to  statement  can  be  used 

:51:  go  to  RULES: 


•ffacts  and 

post-conditionr  the  rule  input  part  of  the  program  is  given  control 
for  further  processing 

Ou)  :52: 

assumptions:  requires  the  ability  to  invoke  :3:,  ERROR,  with  a 

string  message,  which  does  not  return  but  handles 
further  processing 

:52:  ERRULE  I.  E. 


ERRORfRULE  NOT  CORRECT"); 


•ffacts  and 

post-conditions:  :3:,  ERROR,  has  been  invoked  and  handles  further 

processing 
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(>v)  :53: 

assumptions:  requires  the  ability  to  invoke  :3:,  ERROR,  with  a 

string  message,  which  does  not  return  but  handles 

further  processing 

:53:  ERRDATA  I.E. 

ERRORECOATA  NOT  CORRECT"); 

effects  and 

post-conditions:  *3:,  ERROR,  has  been  invoked  and  handles  further 

processing 

(>w)  .54: 

assumptions:  requires  the  ability  to  invoke  :3:,  ERROR,  with  a 

string  message,  which  does  not  return  but  handles 

further  processing 

:54:  ERRGEN  I.E. 

ERRORCGENERIC  VARIABLE  IN  DATA”); 

effects  and 

post-conditions:  :3:,  ERROR,  has  been  invoked  and  handles  further 

processing 

(>x)  :55: 

assumptions:  requires  read/write  access  to  QK,  G  is  a 

one-dimensional  array  such  that  G[i)  -  -1  if  generic 
variable  i  is  not  defined  after  a  successful  search 
for  a  left  part  of  a  rulei,  otherwise  G[i]  >  0  and 

is  the  character  corresponding  to  the  generic  i, 
requires  write  access  to  G,  NG  contains  the  number 

of  generic  variables  encountered  for  the  current 
algorithm,  requires  read  access  to  NG 

:55:  INITGEN  I.E. 

for  QK  «-  1  step  1  until  NG  do 
G[QK]  -  -lj 

effects  and 

post-conditions:  the  definitions  of  the  generic  variables  have  been 

set  to  undefined 
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(>y)  :65: 

assumptions:  requires  read  access  for  A,  assumes  Y  is  a  legal 

character  pointer  into  the  right  part  of  a  rule 
whose  first  character  is  named  by  X  ♦  LENGTHL(X)  + 
A,  requires  ability  lo  invoke  LENGTHL  which  has  the 
value  of  the  number  of  characters  in  the  left  part 
of  the  rule  named  by  its  parameter 

:65:  PULRTCHR(X.Y)  I.E. 

RULRTCHR  ♦-  A[X  +  LENGTHL(X)  +  3  +  Y]  ; 

effects  and 

post-conditions:  RULRTCHR  is  the  Y-th  character  in  the  right  part  of 

rule  X 

(>z)  :66. 

assumptions:  G  is  a  one-dimensional  array  such  that  G[i]  ■  if 

generic  variable  i  is  not  defined  after  a  successful 
search  for  a  left  part  of  a  rulei,  otherwise  G[i]  > 
0  and  is  the  character  corresponding  to  the  generic 
i,  requires  read  access  to  G 

:66:  UNDERX)  I.E.  UNDEF  ♦-  G[-X]  >  0; 

•ffacts  and 

post-conditions:  UNDEF  «■  trua  if  no  definition  for  the  generic 

indicated  by  X  exists;  otherwise  false 

«a)  :67: 

assumptions:  requires  read  access  for  A,  requires  ability  to 

invoke  LENGTHL  which  has  the  value  of  the  number  of 
characters  in  the  left  part  of  the  rule  named  by  its 
parameter,  assumes  A[X  «  LENGTHL(X)  +  3]  is  the 
number  of  characters  in  the  right  part  of  rule  X 

:67:  LENGTHR(X)  I.E. 

LENGTHR  «-  A[X  +  LENGTHL(X)  ♦  3]; 

effects  and 

post-conditions:  LENGTHR  equals  the  length  of  the  right  part  of  the 

rule  indicated  by  X 
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«b)  :68: 
assumptions: 


•(facts  and 
post-conditions: 

«c)  :70: 

assumptions: 


•fleets  and 
post-conditions: 


G  is  a  one-dimensional  array  such  that  G[i]  -  -1  if 
generic  variable  i  is  not  defined  after  a  successful 
search  for  a  left  part  of  a  rulei,  otherwise  G[i]  > 
0  and  is  the  character  corresponding  to  the  generic 
i,  requires  read  access  to  G 

:68:  VALG(X)  I.E. 

VALG  «-  G[-X]; 


VALG  equals  the  character  associated  with  the 
generic  variable  indicated  by  X 


requires  read  access  for  A,  assumes  read  access  to 
X  and  assumes  that  the  length  of  the  left  part  of  a 
rule  named  by  X  is  contained  in  A[X  +  2] 

:70:  LENGTHL(X)  I.E. 

LENGTHL  -  A[X  +  2]; 


LENGTHL  is  the  length  in  characters  of  the  left 
part  of  the  rule  named  by  X 
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I  23456789  10111213141516171819202122232425 


>a 

1-4-  1  • 

>b 

1-4-2! 

>c 

1-  4-  3-  1 

>d 

I-4-3-2 

>e 

1-4- 3- 3 

>f 

1-  4-  3-  4 

>8 

I-  4-  3-  5 

>h 

14-3-6 

>i 

40! 

>j 

41J 

>k 

42: 

>1 

43** 

>m 

44! 

>n 

45! 

>0 

46! 

>P 

47! 

>q 

48! 

>r 

49! 

>8 

50! 

>t 

•  51 ! 

>u 

52* 

>v 

53! 

>w 

54! 

>x 

!55! 

>y 

!  65! 

>z 

!  66* 

<a 

!  67! 

<b 

5  68! 

<c 

!  70* 
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>J 

:  |.  4.  |J 

>b 

:  |.  2* 

>c 

*  I- 4-3-  l 

>d 

!  I-  4  3-  2 

>o 

*  1-4-  3-  3 

>f 

:  1-4-  3-  4 

>g 

:  1-4-  3-  5 

>h 

•  1  •  4-  3-  6 

>i 

•  40* 

>j 

•41* 

>K 

•42* 

>1 

•  43* 

>m 

•  44* 

>n 

•  45* 

>0 

•  46* 

>P 

•  47* 

>q 

•48* 

>r 

*  49* 

>s 

*50* 

>t 

*51* 

>u 

*52* 

>v 

*53* 

>w 

*54* 

>x 

*55* 

>y 

*65* 

>z 

*66* 

<a 

*67* 

<b 

*  68* 

<c 

*70* 

2829303 1 3233343536373839404 14243444546474849505 1 52 

1  I 


I  I 


I 

I 

I 


1 


1 

I 

I 
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>a 

I-  4-  I** 

>b 

1-  4-  2' 

>c 

1  4-3’  1  • 

>d 

I-  4-  3-  2* 

>o 

I-  4-  3-  3" 

1-4  3-4*« 

>g 

1-4- 3-  5! 

>h 

1-4-3-  6! 

>i 

40* 

>j 

4 1  * 

>K 

42* 

>1 

43* 

>m 

44* 

>n 

45* 

>0 

46^ 

>P 

.47: 

>q 

48* 

>r 

:49s 

>s 

=  505 

>t 

5  5 1 5 

>u 

:525 

>v 

5  535 

>  w 

S54S 

>x 

5  555 

>y 

5  65! 

>2 

5  66** 

<« 

5  675 

<b 

5  685 

<c 

5  70S 
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>•  :  i- 4-  1* 

>b  2: 

>c  :  i .  4-  3- 1  s 
>d  :  l  •  4-  3-  2- 
>•  2  1  •  4-  3-  3i 

>f  :  1.  4-  3-  4« 
>8  :  I  -  4-  3-  5= 

>h  :|.4-3-6i 

>1  :<io: 

>j  !4!! 

>k  :  42* 

>1  S43S 

>m  :qq: 

>n  *  /j5* 

>0  * 

>P  i47‘* 

>q  : 48: 

>r  s/jg: 

>s  j  r,0: 

>t  15|S 
>u  S52S 

>V  :53s 

>w  :  54: 

•  55* 

>y  • 65* 

>Z  : 66: 

<8  .*  67  J 

<b  ■  68** 

<c  :  70* 


202 1 2223242526272829303 1 
1 

I  I  1  I  1111  I 
1 

!  I 
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>a 

M'  l: 

>b 

14  2 : 

>c 

1-4  3  1 

>d 

I-4-3-2 

>e 

!•  4-  3-  3 

>f 

I-  A-  3-  4 

>g 

1  •  4-  3-  5 

>h 

I-  4-  3-  6 

>i 

40* 

>j 

4 1  • 

>k 

42* 

>1 

43* 

>m 

44* 

>n 

45: 

>0 

46* 

>P 

47: 

>q 

48* 

>r 

49: 

>s 

50* 

>t 

:  5 1 : 

>u 

52* 

>v 

'53'- 

>w 

:54*« 

>x 

55* 

>y 

65« 

>2 

66* 

<a 

67l 

<b 

:68: 

<c 

70* 

3233343536373839404 1 4243444546474849505 1 5253545556575859606 1 6263646566 
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>a 

!  1-4-  is 

>b 

•  1  •  4'  2* 

>c 

:  1  •  4-  3-  1 

>d 

:  I-  4  3-  2 

>• 

:  I-  4.  3’  3 

>f 

:  |.  4.  3.  4 

>8 

:  I-  4-  3-  5 

>h 

:  1  4-  3-  6 

>i 

•  40* 

>j 

:  4 1 : 

>k 

•  42* 

>1 

••435 

>m 

544: 

>n 

•  45* 

>0 

•  46* 

>P 

547: 

>q 

•  48* 

>r 

5  495 

>s 

•  50* 

>t 

•51* 

>u 

•*52! 

>v 

••535 

>  w 

5  54: 

>x 

:55i 

>y 

!65! 

>z 

•  66* 

<a 

5671 

<b 

*  68’ 

<e 

•  70’ 

676869707 1 7273747576777879808 1 8283848586878889909 1 9293 
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1)  requires  the  ability  to  invoke  :3:„  ERROR,  with  a  string  message, 

which  does  not  return  but  handles  further  processing 

2)  requires  ability  to  invoke  NEXTCARD  which  makes  a  new  card  image 
available,  i.e.  ability  to  invoke  :2:  and  returns  to  the  invoker 

only  if  a  card  for  the  current  algorithm  is  available 

3)  NEXTCHAR  is  the  value  of  the  character  which  immediately 
follows  the  character  of  the  current  card  image  produced  by 
the  last  call  of  NEXTCHAR 

A)  an  end-of-file  condition  has  occurred 

5)  requires  the  ability  to  invoke  the  termination  of  the  entire 

program,  i.e.  :1.5:  ENDOFFIIE 

6)  requires  the  ability  to  invoke,  ALGINIT  (:  1. 1. 1 :) 

the  start  of  processing  for  a  new  algorithm 

7)  CP  is  an  index  into  C  and  indexes  the  last  character  which 

was  produced  as  a  value  from  NEXTCHAR.  After  an  execution 
of  NEXTCARD,  :2:,  CP  must  equal  0 

8)  write  access  required  for  CP 

9)  C[l]  ...  C[80]  contains  the  characters, 

in  order,  of  the  card  image  which  is  inputted  as  a  result 
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of  the  last  execution  of  GETIMAGE 

10)  requires  read  access  to  C 

11)  requires  ability  to  invoke  GETIMAGE  which  inputs  a  card 
and  returns  to  the  cailer  only  if  a  card  was  inputted 

12)  in  columns  1  and  2  indicate  that  the  program  is  to  terminate 
and  a  in  column  1  only  indicates  that  a  new  algorithm 

is  to  be  processed 

13)  requires  ability  to  print  the  string  argument  which  is  passed  as 

the  parameter  to  ERROR 

14)  ability  to  perform  printing  operations 

15)  requires  ability  to  invoke  :1.4:  which  processes  the  remaining 

data  images  for  this  algorithm 

16)  requires  write  access  to  PR 

17)  pr  =  true  means  "print  the  register  after  each  successful 
apolication  of  a  rule;  otherwise  d  not  print  the  register 
after  each  successful  application  of  a  rule 

18)  MAXA  equals  the  maximum  number  of  alphabets  permitted  for 

an  algorithm 

19)  requires  read  access  to  MAXA 

20)  requires  ability  to  set  the  failure  routine  for  NEXTCHAR,  i.e. 
the  ability  to  invoke  SETFAIL  with  a  variable  which  names 
the  part  which  is  to  be  invoked  if  no  more  characters  are 
available  from  NEXTCHAR 

21)  NG  contains  the  number  of  generic  variables  encountered 
for  the  current  algorithm 

22)  CG[i],  1  <  i  <  NG,  equals  the  i-th  generic  variable 
encountered  for  the  current  algorithm 

23)  AG[i],  1  <  i  <  NG,  equals  the  alphabet  name  which 
CG[i]  is  a  generic  variable 

24)  a  failure  routine  has  been  set  if  NEXTCHAR  cannot 
provide  additional  characters  from  the  current  image 

25)  read  access  to  DOT,  COMMA,  COLON,  SEMI,  OPEN,  CLOSE  which 

contain  the  values  of  "C,  ")" 

26)  assumes  write  access  to  CHAR 

27)  assumes  read  access  to  CHAR 

28)  requires  ability  to  invoke  RULES  which  names  the  rule  input 
part,  but  since  RUlES  is  a  label  in  the  main  program 

a  go  to  statement  can  be  used 

29)  ERRHEAD  assumes  compete  control  when  invoked 

and  handles  error  messages  and  further  processing 

30)  NA  equals  the  number  of  alphabets  which  have  been  processed 

thus  far  for  the  current  algorithm 

31)  requires  read  accesss  to  NA 

32)  requires  write  access  to  NA 

33)  requires  read/write  access  to  NOIT,  which  controls  a 
loop  that  process  alphabets 

34)  requires  ability  to  invoke  STORALPH,  which  stores  the  alphabet 
character  if  all  requirements  are  met, otherwise  STORALPH 
invokes  appropriate  error  routines 

35)  requires  read/write  access  to  N0IT1,  which  controls  a  loop 
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that  processes  generics 

36)  requires  ability  to  invoke  STORGEN  which  stores  the  content 

of  CHAR,  if  legal,  otherwise  invokes  the  apporpriate 
error 

37)  requires  ability  to  invoke  ALPHFIN  which  cmpletes  any 
needed  processing  after  an  entire  alphabet  has  been 
stored 

38)  either  no  alphabets  have  been  processed  of  all  alphabets 
processed  have  been  correct 

39)  requires  ability  to  invoke  FAIL  which  correctly  determines 
which  objects  assume  control 

40)  read  access  required  for  CP 

41)  read  and  write  access  required  for  the  variable  I 

42)  requires  ability  to  invoke  TESTLEGAL  which  returns  only  if 

CHAR  is  not  "i". 

43)  requires  ability  to  invoke  TESTGEN  which  returns  only  if 

CHAR  is  not  equal  to  an  already 
used  generic  variable  for  this  algorithm 

44)  A  names  a  one-dimensional  array,  which  from  UPA  to  its 
upper  bound  contains  alphabetic  characters 

45)  requires  read  access  for  A 

46)  NG  contains  the  number  of  generic  variables  encountered 
for  the  current  algorithm 

47)  requires  read  access  to  NG 

48)  requires  write  access  to  NG 

49)  requires  write  access  to  AG 

50)  CHAR  contains  the  next  unstored  character 

from  the  alphabet  or  generics  being  currently  processed 

51)  AL[1]  ...  AL[NA]  names  the  index  of  the  lower  bound  of  the 
characters  in  an  alphabet,  i.e.  Al[i]  is  the  lower 

bound  for  the  i-th  alphabet  and  Al[i-1]  is  the 
upper  bound  for  that  alphabet,  where  AL[0]  equals  the 
initial  value  plus  1  of  UPA 

52)  requires  read  access  to  AL 

53)  requires  ability  to  invoke  ERRGEN,  which  assumes 
control  and  invokes  an  appropriate  error  routine 

54)  requires  ability  to  invoke  TESTAl  which  returns  only  if 

CHAR  is  not  equal  to  a  character  which  has  already  occurred  in  the 
alphabet  currently  being  processed 

55)  requires  ability  to  invoke  TEST  which  returns  only  if  there 
storage  space  as  indicated  by  the  values  of  LPA  and  UPA 

56)  UPA  names  the  last  cell  of  an  array  into  which  an  alphabetic 
character  was  stored,  counting  from  the  top  of  some 
one-dimensional  array.  UPA  is  decremented  by  1 

each  time  an  available  cell  needs  to  be  named 

57)  requires  read  access  to  UPA 

58)  requires  write  access  to  UPA 

59)  A  names  a  one-dimensional  array,  which  from  UPA  to  its 
upper  bound  contains  alphabetic  characters 

60)  requires  write  access  for  A 


. 
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61)  requires  write  access  to  AL 

62)  LPA  names  the  las  cell  of  an  array  into  which  rules 
are  stored,  counting  from  the  lower  bound  of  a 
one-dimensional  array  .  LPA  is  incremented  by  one  each 
time  an  available  cell  needs  to  be  named 

63)  requires  read  access  to  LPA 

64)  LPA  and  UPA  are  index  variables  for  the  same  array 

65)  requires  read  access  to  CG 

66)  requires  write  access  to  CG 

67)  requires  read/write  access  to  J 

68)  requires  read/write  access  to  K 

69)  requires  read  access  for  A 

70)  requires  ability  to  invoke  INITRA,  which  initializes  the 

input  part  for  rules  for  a  new  algorithm 

71)  requires  ability  to  invoke  CARDISRULE  which  determines 

whether  the  current  card  image  is  to  be  interpreted  as 
as  a  rule  or  not 

72)  requires  ability  to  invoke  PRINTCARD 

which  prints  the  current  card  image 

73)  requires  ability  to  invoke  EOR,  eid  of  rules  condition 

processor 

74)  requires  ability  to  invoke  INITR  wnich  initializes 

for  inputting  a  new  rule 

75)  requires  ability  to  invoke  LABL  which  collects  a  label 

terminated  by  the  character  in  TERM  and  leaves  the  integer 
label  value  in  LAB 

76)  requires  ability  to  invoke  STORLABEL  which  associates 

the  label  with  the  current  rule 

77)  requires  write  access  to  TERM 

78)  ability  to  invoke  STORCHAR  which  returns  only  if  the 

content  of  CHAR  could  be  successfully  stored  with  rule 
being  processed 

79)  requires  ability  to  invoke  INITR1GHT  which  initializes 

for  processing  the  input  of  a  right  part  of  a  rule 

80)  requires  ability  to  invoke  PROCTERM  which  indicates  a  rule  as 

a  terminal  rule;  requires  ability  to  invoke  PROCSUC 
which  processes  the  successor  part  of  a  rule 

81)  requires  read  access  io  LAB 

82)  a  negative  value  in  LAB  indicates  that  no  label  was  collected 

83)  after  rule  initialization,  A[N1]  -  1  =  NR,  N1  names  the 

current  rule  A[N1]  =  -1,  N2  =  Nl  +  1,  A[N2]  =  2,  NE  =  N1  +  2 

and  the  location  which  is  the  name  of  the 

immediately  preceding  rule  names  the  current  rule,  thus  if 

Nl’  is  the  value  of  N1  prior  to  this  initialization 

*;ien  A[N1’]  =  N1  -  unless  NR  «  1  in  which  case  the  previous 

value  of  NL  is  not  defined 

84)  R  names  a  one -dimensional  array 

which  contains  pointers  to  rules  such  that  label  i 
names  rule  R[i ]; 

R[0  -  0  means  label  i  is  not  defined; 
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R[i]  >  0  means  the  label  is  defined  and 
R[i]  is  a  pointer  to  the  rule  it  namws; 

R[i]  <  0  means  that  label  i  is  undefined  but  has 
been  referenced  by  rule  -R[i]  and  is 
the  head  of  a  chain 

85)  requires  write  access  to  R 

86)  requires  read  access  to  R 

87)  A  names  a  one-dimensional  array  which  from  its 

lower  bound  to  LPA  contains  representations  of  rules 

88)  requires  read  access  to  NE 

89)  NE  names  a  cell  in  A  such  that  A[NE]  indicates  the  current  number 

of  characters  in  the  rule  part  being  processed  -  left  part 
if  the  left  part  is  being  processed  or  right  part  if  the 
right  part  is  being  processed 

90)  requires  write  access  to  LPA 

91)  at  most  100  labels  are  permitted  and  their  definitions 

appear  in  the  one-dimensional  array  R[l:100]  such  that 
R[i]  contains  the  definition  of  label  i  when  the  label 
is  interpreted  as  a  positive  integer 

92)  NR  indicates  the  rulename  which  is  currently 

being  processed 

93)  requires  read  access  to  NR 

94)  requires  write  access  to  NR 

95)  requires  write  access  to  NE 

96)  TERM  contains  the  non-digit  character  which  is  expected 
to  terminate  a  label 

97)  requires  read  access  to  TERM 

98)  the  digits  "0",  "1",  "2",  ...  ,  "9"  are  represented  by  character 

codes  such  that  "0"  -  ZERO  =  0,  ...  ,”9"  -  ZERO  =  9 
and  the  only  legal  label  characters  are  digits  and  BLANK 

99)  read/write  access  to  LAB  is  required 

100)  legal  range  of  labels  is  1  through  100 

101)  BLANK  contains  the  representation  of  a  space  and  ZERO 
contains  the  representation  of  a  zero 

102)  requires  read  access  to  BLANK  and  ZERO 

104)  assumes  LAB  contains  a  legal  label  name  or  -1  which 
indicates  that  no  label  has  been  concatenated 

105)  requires  write  access  to  LAB 

106)  N1  names  the  rule  being  currently  inputted 

107)  requires  read  access  !o  N1 

108)  ERRULENAME  contains  the  value  which  indicates  a  routine 
which  can  take  control  if  an  error  is  discovered  as  rules 
are  being  stored 

109)  requires  read  access  to  ERRULENAME 

110)  requires  read  access  to  N2 

111)  requires  read/write  access  to  L 

112)  requires  write  access  to  N2 

113)  a  colon  in  column  4  when  processing  rules  indicates  that 
the  card  is  to  be  interpreted  as  a  rule 

114)  requires  read/write  access  to  Q 
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115)  a  value  of  -1  in  A[N2]  indicates  that  the 
rule  is  a  terminal  rule 

116)  ERRHEADNAME  is  a  variable  which  names  the  routine  ERRHEAD 

117)  requires  read  access  to  ERRHEADNAME 

118)  RULESNAME  is  a  variable  which  names  the  routine  RULES  which 
inputs  the  rules  for  an  algorithm 

119)  requires  read  access  to  RULESNAME 

1 20)  assumes  all  rules  have  been  inputted  correctly; 

assumes  that  the  current  card  isrepresents  an  initial  register 

contents;  assumes  that  NEXTCARD  returns  control  only  if 

a  data  image  is  available  for  the  current  algorithm 

121)  requires  the  ability  to  invoke  :4:,  ERRORE,  with  a  string 
message,  which  does  not  return  but  handles  further  processing 
at  the  execution  stage 

122)  ERRDATANAME  contains  a  value  which  indicates  a  routine 
which  indicates  a  routine  which  can  take  control  if  an  error  is 
discovered  while  an  initial  register  contents  is  being  input 

123)  requires  read  access  to  ERRDATANAME 

124)  REG,  is  a  one-dimensional  array  which  contains 
the  characters  in  the  regisfer 

125)  assume  -,  read  access  to  REG 

126)  assumes  write  access  to  REG 

127)  requires  read/write  access  to  RPP  which  is  used  as 

a  temporary  register  position  pointer  when  the  register 
is  being  innally  filled 

128)  requires  read/write  access  to  RC  which  is  used 

to  contain  single  characters  from  the  current  da*a  card  when 
the  register  is  being  filled 

129)  assumes  read  access  to  MAXRL  which  contains  the  maximum  number 
of  characters  permitted  in  the  register 

130)  requires  write  access  to  MAXT1 

131)  requires  write  access  to  RL 

132)  the  name  of  the  first  rule  is  2 

133)  MAXT1  contains  the  number  of  trial  rule  applications 
still  permitted  for  this  execution  of  an  algorithm 

134)  write  access  to  RULENAME  required 

135)  requires  read  access  to  TRM 

136)  FIN  is  a  result  of  NOSUC  which  indicates  that  there  are  no  more 
rules  which  can  be  applied 

137)  requires  read  access  to  FIN 

138)  read  access  to  RULENAME  required 

139)  TRM  is  a  result  of  SUCSUC  and  UNSUCSUC  which 
indicates  that  the  algorithm  should  terminate,  i.e.  TERM 
names  no  legal  and  indicates  termination 

140)  requires  ability  to  invoke  SEARCH  which 
searches  for  a  match  of  the  left  part  of  rule 
RULENAME,  and  which  refurns  the  value  true  if 
a  match  is  found,  false  otherwise 

141)  requires  read  access  to  MAXT1 

142)  requires  ability  to  invoke  REPLACE,  which  has  the  effect  of 
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replacing  the  register  contents  with  the  right  part  of  the 
rule  named  by  RULENAME,  where  the  left  part  was  matched 

143)  requires  the  ability  to  invoke  SUCSUC  which  has  the  value  of  the 
success  to  rule  RULENAME  for  a  successful  application 

of  rule  RULENAME 

144)  requires  the  ability  to  invoke  UNSUCSUC  which  has 

the  value  of  the  name  of  the  successof  to  rule  RULENAME 
after  an  unsuccessful  application  of  rule  RULENAME 

145)  assumes  A[RULENAME  +  1]  names  the  successor  for  rule  RULENAME 
for  a  successful  application  of  rule  RULENAME 

146)  requires  read  a  cess  to  PR 

147)  requires  the  ability  to  invoke  PRINTREG  which 
prints  the  contents  of  the  register 

148)  if  RULENAME  =  TRM  then  dot  termination  has  occurred,  otherwise 
the  rules  have  been  exhausted 

149)  G  is  a  one-dimensional  array  such  that  G[i]  =  -1  if  generic 
variable  i  is  not  defined  after  a  successful  search  for  a  left 
part  of  a  rulei,  otherwise  G[i]  >  0 

and  is  the  character  corresponding  to  the  generic  i 

150)  requires  read  access  to  G 

151)  requires  write  access  to  G 

152)  requires  read/write  access  to  NMAT 

153)  assumes  that  a  generic  in  a  rule  has  been  saved 
as  a  negative  value 

154)  assumes  Q  is  a  leg  j|  character  pointer  into  the  left 
part  of  a  rule  whose  first  character  is  P  +  3 

155)  assumes  A[RULENAME]  names  the  successor  rule  for  rule  RULENAME 
after  an  unsuccessful  application  of  rule  RULENAME 

156)  requires  the  ability  to  invoke  LEFT  which  names  the  location 
which  is  the  first  character  of  the  left  part  of  rule,  RULENAME 

157)  requires  ability  to  invoke  LENGTHL  which  has  the  value  of  the 
number  of  characters  in  the  left  part  of  the  rule  named 

by  its  parameter 

158)  LEN  names  the  number  of  the  character  in  the  left  part 
of  the  rule  currently  being  processed 

159)  requires  read  access  to  LEN 

160)  requires  write  access  to  LEN 

161)  LFT  names  the  starting  location  for  the  left  part  of  the  current 
rule  name 

162)  requires  read  access  to  LFT 

163)  requires  write  access  to  LFT 

164)  requires  read/write  access  to  NOSUC 

165)  RL  contains  the  current  register  length 

166)  requires  read  access  to  RL 

167)  requires  ability  to  in  nke  RULLFTCHR(A.B)  which 
produces  the  value  of  ,he  B-th  character  of 

the  left  part  which  starts  at  A 

168)  RP  names  the  character  position  where  a 
character  sequence  is  to  be  replaced 

169)  requires  read  access  to  RP 
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170)  requires  write  access  to  RP 

171)  assumes  LI  /  L2 

172)  requires  abil  ty  to  invoke  GENERIC  which 

has  the  value  true  if  its  parameter  represents  a 
generic  variable 

173)  requires  read/write  access  to  CC 

174)  requires  read/write  access  to  LHP 

175)  requires  ability  to  invoke  ADJUST  whose  first  parameter 
indicates  the  number  of  characters  in  the  left  part 

of  a  rule  r,d  whose  second  parameter  indicates  the  number 
of  characters  in  the  right  part  of  tb  rule.  ADJUST 
modifies  the  register,  if  necessary,  so  that  the  right 
part  can  be  inserted  where  the  matched  left  oart  is 

176)  requires  ability  to  invoke  INSERT  which  inse.ts  the  appropriate 
right  part  over  the  matched  left  part 

177)  requires  ability  to  invoke  LENGTHR  which  returns  the  value 
of  the  number  of  characters  in  the  right 

part  cf  the  rule  named  by  its  parameter 

178)  requires  read/write  access  to  LEN  and  LENR 

179)  requires  read  access  to  LENR 

180)  requires  write  access  to  LENR 

181)  requires  read  acress  to  LI,  L2,  and  TPj  1.1  contains  the 
length  of  a  character  sequence  Deing  replaced  by  a 
character  sequence  of  length  L2 

182)  requires  read  write  access  to  TQ  and  CQ 

183)  requires  ability  to  invoke  RULRTCHAR(A)  which  returns  the 
character  which  is  the  A-th  character  of  the  right  side 

of  rule  RULENAMF 

184)  requires  the  ability  to  invoke  UNDEF(A)  which  returns  the  value 
true  if  A  is  an  undefined  generic  variable 

representation  for  this  rule  application;  false  otherwise 
185;  requires  ability  to  invoke  VALG(A)  which  produces  the 
character  associated  with  ihe  generic  representation  A 
for  this  rule  application 

186)  assumes  LENR  contains  the  length  of  the  string 
being  inserted 

187)  requires  read  access  to  AG 

188)  assumes  Y  is  a  legal  character  pointer  into  the  right  part 
of  a  rule  whose  first  character  is  named  by  X  +  LENGTHL(X)  +  4 

189)  assumes  X  +  2  is  an  index  which  names  the  first  character  of  the 
left  part  of  a  rule  -1 

190)  assumes  A[X  +  LENGTHL(X)  +  3]  Is  the  number  of  characters 
in  the  right  part  of  rule  X 

191)  assumes  read  access  to  X  and  assumes  that  the  length 

of  the  left  part  of  a  rule  named  by  X  is  contained  in  A[X  +  2] 

192)  requires  read  access  to  RULENAME 

193)  reauires  read/write  access  tc  QK 
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An  analysis  of  the  final  stage  using  the  measure  has  led  to  the 
following  good  decomposition 

((a)  (On)  (Or)  ((>t)  ((r)  <(>a)  ((e)  ((f) 

((  >s,  >u,  >w)  ((s)  ((*x)  ((i)  ((k,  o)  ((i)  ((g,  h) 

((v,  w)  ((x)  ((#a,  #b,  *c,  *d,  *f,  *g,  *h,  *i,  *j,  #1) 

(Oc,  >d,  >f,  >g)  («b,  >z,  >x,  >m) 

(Oo,  >y,  >p,  >q,  <c,  <a)  (Oe,  >h,  >v) 

((*s,  #r,  #q,  *u,  *v)  ((u,  y)  (Oj,  >k,  >i,  >1,  >b) 

((2,  t)  ((*o,  #p,  *w,  *t)  ((m,  p,  q)  ((*k,  #n,  *m)) 

1.56  )  1.65  )  1.52  )  1.60  )  1.35  )  1.41  )  1.20)  .92  ) 

.52  )  .32  )  1.08  )  1.25  )  1.02  )  .65  )  .77  )  .32  )  .34  ) 

.53  )  .50  )  .47  )  .22  )  .04  )  .04  )  .04  )  .04  )  .05  )  .05  )  0 

t 

This  decomposition  is  not  the  best  decomposition,  but  it  illustrates  the 
result  of  using  the  measure  to  produce  a  good  decomposition  which 
satisfies  several  of  the  properties  stated  in  the  Introduction. 

Specifically,  those  objects  which  manipulate  the  representation  of  rules 
appear  together.  This  situation  along  with  others  demonstrates  that  the 
decomposition  appears  to  have  several  of  the  independence  properties 
stressed  by  Parnas.  The  parts  FAIL,  SETFAIL,  and  the  initialization 
portion,  though  not  elaborated  here,  localize  detailed  information  about 
the  flow  of  control  in  the  program  and  interact  little  with  the  previous 


elaborations. 
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McKeeman[MKl],  in  a  paper  entitled  "Compiler  Structure”,  has 
presented  several  guides  that  aid  in  fragmenting  a  compiler  into 
modules.  Does  such  a  modularization  possess  good  structure  in  the  sense 
of  the  definition  and  measure  presented  in  this  thesis?  It  is  probably 
the  case  that  these  modularizations  could  have  good  structure,  but  good 
structure  is  not  guaranteed. 

The  two  kinds  of  fragmentation  discussed  are  vertical  fragmentation 
and  horizontal  fragmentation. 

Vertical  fragmentation  corresponds  to  decomDOSitions  whose  modules 
may  be  regarded  as  "passes"  or  "phases"  lr,  the  compilation  process. 
Each  module  accepts  as  input  the  output  of  a  previous  module.  Thus,  a 
possible  vertical  decomposition  for  ?  compiler  is 


INPUT 

A 

(analyze  text  to  produce 
a  sequence  of  Single  characters) 

V 

SCAN 

i 

(analyze  single  characters  to 
produce  tokens) 

PARSE 

i 

(analyze  tokens  to  produu  a 
parse  tree) 

SYNTHESIS 

1 

(analyze  parse  tree  to  produce 
a  computation  tree) 

GENEFATE 

1 

(analyze  computation  tree  to 
produce  language  specific  code) 

EMIT 

i 

(analyze  language  specific  code  to 
get  machine  specific  code) 

V 

OUTPUT 

(analyze  code  to  get  executable 
or  loadable  text) 
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McKeeman  stresses  the  importance  of  precisely  describing  the 

intermediate  languages  that  connect  the  modules  and  provides  examples  of 
such  intermediate  languages.  Hence,  pairs  of  successive  modules  share 
information  about  their  intermediate  languages.  This  can  lead  to  many 
interactions  between  adjacent  modules.  An  alternative  that  has  been 

displayed  in  Appendix  1  and  in  the  work  of  Parnas,  is  to  provide 

additional  modules  which  make  information  about  the  intermediate 
languages  available.  This  eliminates  the  need  for  sharing  the  entire 
grammar  of  the  intermediate  language.  Thus  changes  to  these 

intermediate  languages  correspond  to  adding  or  deleting  or  changing 
functions  at  the  interface.  The  measure  indicates  that  the  modules  in 
this  alternative  interact  less  than  in  the  modularization  suggested  by 
McKeeman  -  at  the  expence  of  requiring  additional  modules. 

horizontal  fragmentation  can  be  used  to  further  fragn.^nt  nodules  in 


some  vertical  fragmentation. 
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McKeeman  presents  the  following  Horizontal  fragmentation  for  the  module 
SYNTHESIS 


FAN  OUT 


NULL  DEFINE  OPERAND  OPERATE  ASSIGN  SEQUENCE 


FAN  IN 


FAN  OUT  is  intended  to  pass  appropriate  parts  of  the  phrase  structure 
tree  or  canonical  parse  to  the  modules  beneath  it.  FAN  IN,  recombines 
the  results  of  these  modules  into  a  computation  tree  or  sequence  of 
actions. 

The  final  decomposition  shown  in  Appendix  I  and  the  modularizations 
suggested  by  Parnas[PAl-5]  indicate  that  the  boundaries  of  these  modules 
may  not  be  as  "clean"  as  the  diagram  suggests.  For  example,  information 
contained  in  the  SYMBOL  TABLE  module  may  ^e  required  by  more  modules 
than  are  indicated  by  the  arrows.  (Indeed,  similar  kinds  of  modules 
displayed  in  [MK]  share  far  more  assumptions  !han  are  indicated  by 
either  diagrams  or  text.)  Further,  assumptions  made  by  different  modules 
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may  suggest  additional  modules  in  order  to  maintain  the  independence 
properties  suggested  by  the  diagram.  Indeed,  FAN  IN  and  FAN  OUT  may 
well  share  enough  assumptions  to  warrant  large  parts  of  them  to  be 
written  as  additional  modules. 

Stronger  statements  than  the^e  can  only  be  made  if  more  detailed 
information  about  the  intended  behavior  of  the  modules  is  presented. 


